David Christensen <da...@endpoint.com> writes: > 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.
Oh, yeah, that's interesting. So you could force all the commits to match the timestamp of the first one. That's sort of the wrong end of the process though --- I'd rather have a timestamp closer to when I'm done than when I start. The other thing that comes to mind on further reflection is that by the time you get done with the back-patching, the commit log message might be different from what you thought it would be when you started. I had an example just today: http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=829f5b3571241cae2cc1a02923439cd0725d683c Fixing "make distdir" wasn't part of what I was doing when I started. I suppose I could have done that in a separate series of commits, but if the idea is to make things more efficient not less so, that's not the direction I want to go. So right now I'm thinking that the best approach is to do the work in temporary topic branches, then make up a commit message and use it while doing squash merges onto the public branches. I hadn't thought when I went into this that a two-line patch would justify a temporary branch, but if you need to back-patch it, maybe it does. In principle I guess that we could decide to use -c or -C for the squash merges and thus make their commit timestamps exactly the same not only approximately the same. This seems a bit overly anal retentive to me at the moment, but maybe sometime in the future it'll be an idea worth adopting. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
