<br /><br /> On 09/21/2010 09:20 PM, Tom Lane wrote: <blockquote cite="mid:13289.1285118406@sss.pgh.pa.us"
type="cite"><prewrap="">Okay, so now that I've actually done a couple of multi-branch commits...
I'm using the multiple-work-directory arrangement suggested on our wiki
page. The work flow seems to boil down to:
* Prepare patch in master
* Stage patch with git add
* git diff --staged >/tmp/patch-head
* cd into REL9_0_STABLE workdir
* patch -p0 </tmp/patch-head
* Adjust patch if needed
* Stage patch with git add
* git diff --staged >/tmp/patch-90
* cd into REL8_4_STABLE workdir
* patch -p0 </tmp/patch-90
* ... lather, rinse, repeat ...
* cd back to master
* git commit -F /tmp/commitmsg
* cd into REL9_0_STABLE workdir
* git commit -F /tmp/commitmsg
* cd into REL8_4_STABLE workdir
* git commit -F /tmp/commitmsg
* ... lather, rinse, repeat ...
* git push
While this isn't much worse than what I was used to with CVS, it's
definitely not better. I think that I could simplify transferring the
patch back to older branches if I could use git cherry-pick. However,
that only works on already-committed patches. If I commit in master
before I start working on 9.0, and so on back, then the commits will be
separated in time by a significant amount, thus destroying any chance of
having git_topo_order recognize them as related. So we're back up
against the problem of git not really understanding the relationships of
patches in different branches.
One idea that comes to me is to do each patch in a temporary side branch
off that maintenance branch, and then only the final commits merging
that work back to the public branches need be closely spaced. But being
still a git novice, it's not exactly clear to me how to do that, and
anyway it seems like there's still possibility for trouble if there's
unexpected merging failures on some of the branches. (That would only
be an issue if the back-patching took long enough for some of the
branches to change underneath me, which isn't too likely, but if it
did happen how do I recover and still keep the commits close together?)
</pre></blockquote><br /> I suspect you should indeed be working on topic branches for everything non-trivial. You can
safelycommit on them, cherry-pick from them, squash from them onto the main branch, and then discard them. You can
resolveproblems before committing on the main branch by doing:<br /><blockquote>git checkout mainbranch<br /> git merge
--squash--no-commit topicbranch<br /></blockquote> Unless I'm missing something there's no reason you should ever have
tohave a significant delay between branches in commits/pushes.<br /><br /> I know git has something of a learning
curve,but I'm betting that in a month or so you'll be better at using it than most of us ;-)<br /><br /> cheers<br
/><br/> andrew<br />