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?)
So it seems like maybe we still need some more thought about how to
recognize related commits in different branches. Or at the very least,
we need a best-practice document explaining how to manage this --- we
shouldn't expect every committer to reinvent this wheel for himself.
Comments?
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
