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@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +