Re: Multi-branch committing in git, revisited

On 09/21/2010 09:20 PM, Tom Lane wrote:
> 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?)

I suspect you should indeed be working on topic branches for everything
non-trivial. You can safely commit on them, cherry-pick from them,
squash from them onto the main branch, and then discard them. You can
resolve problems before committing on the main branch by doing:

git checkout mainbranch
git merge --squash --no-commit topicbranch

Unless I'm missing something there's no reason you should ever have to
have a significant delay between branches in commits/pushes.

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 ;-)

cheers

andrew