From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | David Christensen <david(at)endpoint(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Multi-branch committing in git, revisited |
Date: | 2010-09-22 03:05:05 |
Message-ID: | 201009220305.o8M355R07932@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Christensen wrote:
> > 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.
>
>
> Is the issue here the clock time spent between the commits, i.e., the
> possibility that someone is going to push to the specific branches in
> between or the date/time that the commit itself displays? Because if
> it's specifically commit time that's at issue, I believe `git
> cherry-pick` preserves the original commit time from the original
> commit, which should make that a non-issue. Even if you need to fix
> up a commit to get the cherry-pick to apply, you can always `git commit
> -C <ref-of-cherry-pick>` to preserve the authorship/commit time for
> the commit in question.
The problem is that the cherrypicks will often have to modified, and it
can take +20 minutes to resolve some of them.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Hitoshi Harada | 2010-09-22 03:06:51 | Re: wip: functions median and percentile |
Previous Message | David Christensen | 2010-09-22 03:02:57 | Re: Multi-branch committing in git, revisited |