Tom Lane wrote: > Marko Kreen <mark...@gmail.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? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
