Re: Managing multiple branches in git

On 6/2/09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> [ it's way past time for a new subject thread ]
>
> Marko Kreen <markokr(at)gmail(dot)com> writes:
> > They cannot be same commits in GIT as the resulting tree is different.
>
> This brings up something that I've been wondering about: my limited
> exposure to git hasn't shown me any sane way to work with multiple
> release branches.
>
> 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:
> pgsql/ ...
> REL8_3/pgsql/ ... (made with -r REL8_3_STABLE)
> REL8_2/pgsql/ ...
> etc
>
> Each of these is configured (using --prefix) to install into a separate
> installation tree. So I can switch my attention to one branch or
> another by cd'ing to the right place and adjusting a few environment
> variables such as PATH and PGDATA.
>
> 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 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. Not to mention the
> impossibility of getting it to regard parallel commits as related
> in any way whatsoever.

Whether you use several branches in one tree or several checked out
trees should be a personal preference, both ways are possible with GIT.

> So how is this normally done with git?

If you are talking about backbranch fixes, then the "most-version
controlled-way" to do would be to use lowest branch as base, commit
fix there and then merge it upwards.

Now whether it succeeds depends on merge points between branches,
as VCS system takes nearest merge point as base to launch merge logic on.

I think that is also the actual thing that Markus is concerned about.

But instead of having random merge points between branches that depend
on when some new file was added, we could simply import all branches
with linear history and later simply say to git that:

* 7.4 is merged into 8.0
..
* 8.2 is merged into 8.3
* 8.3 is merged into HEAD

without any file changes. Logically this would mean that "any changes in
branch N-1 are already in N".

So afterwards when working with fully with GIT any upwards merges
work without any fuss as it does not need to consider old history
imported from CVS at all.

--
marko