Re: Managing multiple branches in git

Tom Lane wrote:
> Marko Kreen <markokr(at)gmail(dot)com> writes:
>> They cannot be same commits in GIT as the resulting tree is different.
> The way I prepare a patch that has to be back-patched is first to make
> and test the fix in HEAD. Then apply it (using diff/patch and perhaps
> manual adjustments) to the first back branch, and test that. Repeat for
> each back branch as far as I want to go. Almost always, there is a
> certain amount of manual adjustment involved due to renamings,
> historical changes of pgindent rules, etc. Once I have all the versions
> tested, I prepare a commit message and commit all the branches. This
> results in one commit message per branch in the pgsql-committers
> archives, and just one commit in the cvs2cl representation of the
> history --- which is what I want.

I think the closest equivalent to what you're doing here is:

"git cherry-pick -n -x <the commit you want to pull>"

The "git cherry-pick" command does similar to the diff/patch work.
The "-n" prevents an automatic checking to allow for manual adjustments.
The "-x" flag adds a note to the commit comment describing the relationship
between the commits.

It seems to me we could make a cvs2cl like script that's aware
of the comments "git-cherry-pick -x" inserts and rolls them up
in a similar way that cvs2cl does.

> The way that I have things set up for CVS is that I have a checkout
> of HEAD, and also "sticky" checkouts of the back branches...
> Each of these is configured (using --prefix) to install into a separate
> installation tree. ...

I think the most similar thing here would be for you to have one
normal clone of the "official" repository, and then use
git-clone --local
when you set up the back branch directories. The --local flag will
use hard-links to avoid wasting space & time of maintaining multiple
copies of histories.

> I don't see any even-approximately-sane way to handle similar cases
> in git. From what I've learned so far, you can have one checkout
> at a time in a git working tree, which would mean N copies of the
> entire repository if I want N working trees....

git-clone --local avoids that.

> ... Not to mention the
> impossibility of getting it to regard parallel commits as related
> in any way whatsoever.

Well - "related in any way whatsoever" seems possible either
through the comments added in the "-x" flag in git-cherry-pick, or
with the other workflows people described where you fix the bug in
a new branch off some ancestor of all the releases (ideally near
where the bug occurred) and merge them into the branches.

> So how is this normally done with git?