On 22/09/10 04:20, 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.
In git, each commit has two timestamps. Author timestamp and committer
timestamp. They are usually the same, but when you cherry-pick, the
cherry-picked commit retains the original author timestamp, while commit
timestamp changes. "git log" shows only the author timestamp, and if I'm
reading git_topo_order correctly, that's what it cares about too. "git
log --format=fuller" can be used to show both.
So AFAICS, if you use cherry-pick, you're fine. Even if you don't for
some reason, you can override the author timestamp with "git commit
--date=<date>".
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
