[ it's way past time for a new subject thread ] Marko Kreen <mark...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers