Big Mess--How to use Git to resolve

Big Mess--How to use Git to resolve

[hs_glw]

I want to use Git, I have had read documentation installed on my local
machine, then looked at my mess of code and don't know what the hell to do.

I have a Perl Web Application, several hundred programs, templates,
configuration files.

Companies buy my application and I host it for them.

I have 40+ clients

Each client has its own unique installation of the software on my web
server.

Some clients have customizations of the code, some have version 5 of the
software others have 5.2, 5.5 etc.

This sucks.

My goal is to pull all the different versions in, put them all together, and
create a master version of the software that runs for all clients.

There will still be some files that are completely unique to each client
(style sheets and logos for instance).

I can't figure out if I should start with my oldest version of the code or
the newest, I haven't really found in the documentation how to start with
different permutations of the code in a repository.   Everything I have
found assumes you start with one set of code, then make changes.  I have
multiple variations and need to get them consistent.

I expect to use all of 2012 getting this put back together, but I have to
start.  Does anyone have any suggestions on how I should set Git up to do
what I need?

--
View this message in context: http://git.661346.n2.nabble.com/Big-Mess-How-to-use-Git-to-resolve-tp7103964p7103964.html
Sent from the git mailing list archive at Nabble.com.

Re: Big Mess--How to use Git to resolve

[Randal L. Schwartz]

>>>>> "hs" == hs glw <greg@hra.net> writes:

hs> Some clients have customizations of the code, some have version 5 of the
hs> software others have 5.2, 5.5 etc.

Create an empty repo.

Unpack the oldest release (I presume you still have the tarballs) you
might have forked a customer from.  commit it, and tag it as v5.0 (or
whatever it is).

In the same dir, delete the files, and unpack the *next* release.  git
add . again, and commit that, effectively recording the changes from one
release to the next.  Tag it v5.1 or whatever.

Repeat for all releases.

git branch -m master release

That will remain your untouched release branch.

Now, take customer1.  Figure out which release is closest to their
modified code.  Let's say it's v5.2

git checkout -b customer1 v5.2

erase the files, copy their work in, and commit.  You'll now have a
customer1 branch that comes off the right release.

repeat for each customer.

So now you have tags for each release, and every customer's code checked
in somewhere.

If you feel brave, you can try to move a customer to a later release:

git checkout customer1
git rebase v5.5

That will try to apply the diff between v5.2 and customer1 directly to
the top of v5.5.  Might fail, might need some mopping up.  But at least
the hard work is done.

Hope this helps.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

Re: Big Mess--How to use Git to resolve

[hs_glw]

Randal, thank you for the comprehensive answer.  I have one follow-up:  we
have the working files, then in our installation files we have .PL files
that are worked on by some iteration of "make" to insert paths both into
.cgi files and config files, should these installation files be setup as a
branch? or is there a more correct way of implementing this?

--
View this message in context: http://git.661346.n2.nabble.com/Big-Mess-How-to-use-Git-to-resolve-tp7103964p7104493.html
Sent from the git mailing list archive at Nabble.com.

Re: Big Mess--How to use Git to resolve

[Holger Hellmuth]

On 17.12.2011 19:40, hs_glw wrote:
> Randal, thank you for the comprehensive answer.  I have one follow-up:  we
> have the working files, then in our installation files we have .PL files
> that are worked on by some iteration of "make" to insert paths both into
> .cgi files and config files, should these installation files be setup as a
> branch? or is there a more correct way of implementing this?

If I understand you correctly the working aka source files are patched 
in place to adapt to a customer. I would suggest changing that a bit so 
that the source filename is different from the installation filename. 
Add the source file into the repo and add the installation filenames 
into .gitignore

That way you don't have generated files in the repository. Which is 
usually avoided because they easily get out of sync with their source.

The renaming should be done so you never erraneously add installation 
files into the repository in place of the source files

Re: Big Mess--How to use Git to resolve

[Neal Kreitzinger]

On 12/17/2011 12:40 PM, hs_glw wrote:
> Randal, thank you for the comprehensive answer.

The technique Randal described sounds like the 'vendor code drop' method 
described in the git-rm manpage.  There you will find detailed 
instructions on the best way to 'erase' the previous version and drop in 
a tarball of the 'newer' version.

Hope this helps.

v/r,
neal

Re: Big Mess--How to use Git to resolve

[Neal Kreitzinger]

On 12/17/2011 12:40 PM, hs_glw wrote:
> Randal, thank you for the comprehensive answer.

Note that Randal's solution leaves with a branch named Release that has 
the history of the generic version of your software, and various 
custom(er) branches that fork from the Release branch...

On 12/17/2011 6:32 AM, hs_glw wrote:
> Some clients have customizations of the code, some have version 5 of
> the software others have 5.2, 5.5 etc.
>
> My goal is to pull all the different versions in, put them all
 > together, and create a master version of the software that runs for
 > all clients.

Note that you don't have to make everyone run the same version. At my 
shop we maintain dozens of concurrent divergent versions and that is the 
main reason we chose git.  We can maintain a generic version (which most 
clients run) and also custom branches (for clients wanting to pay for 
customizations) forked off of the generic branch.  The custom branches 
can periodically have the generic branch merged in to obtain the generic 
fixes/enhancements.  You can also merge the custom branches into the 
generic branch if you want those custom features included in a new 
release of the generic branch.

> There will still be some files that are completely unique to each
> client (style sheets and logos for instance).

If your logos are graphical files they are likely considered 'large 
files' and are likely binary files in the context of git.  It is 
recommended you maintain these in a separate repository to keep them 
from bogging down your main repo (performance and storage).  You can 
make the logo repo a submodule of the main repo (source repo).  This 
would then make your main repo a 'super project' (contains submodules) 
in git terminology.  Alternatively, I think your source repo and logo 
repo can just both be submodules of a super project.

We are working on implementing this so some of what I said is 
theoretical.  Custom branches in combination with submodules seems like 
it could get pretty unwieldy if not managed properly.

Some things to look into.

v/r,
neal

Re: Big Mess--How to use Git to resolve

[Seth Robertson]

In message <4EF26F7B.90206@gmail.com>, Neal Kreitzinger writes:

    We are working on implementing this so some of what I said is 
    theoretical.  Custom branches in combination with submodules seems like 
    it could get pretty unwieldy if not managed properly.

You might want to consider using gitslave (http://gitslave.sf.net)
which is easier to use when you are developing both the superproject
and the subprojects at the same time.  You don't have to use the
"mother-may-I" commit protocol.

The trick with gitslave is that normally you run all git commands on
all repositories at the same time.  So all repositories which are part
of the superproject will be on the same branch.  This sounds like it
is ideal for you.

However, you do lose the strong binding between the superproject
commit and the subproject commit, so you would want to tag all
projects (trivial when using gitslave) when you go through a release
so that you can later go back and check out synchronized repositories
for a particular release.

					-Seth Robertson