Big Mess--How to use Git to resolve

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.

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, 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.

On 17.12.2011 19:40, hs_glw wrote:

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

On 12/17/2011 12:40 PM, hs_glw wrote:

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

On 12/17/2011 12:40 PM, hs_glw wrote:

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:

 > 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.

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

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