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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
