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