Re: Multi-branch committing in git, revisited

David Christensen <david(at)endpoint(dot)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