[ it's way past time for a new subject thread ]
Marko Kreen <markokr@gmail.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.
So how is this normally done with git?
regards, tom lane
