Re: git interactive rebase 'consume' command

Stephen Kelly [off-list ref] writes:

Junio C Hamano wrote:

quoted

Sorry, but I do not understand what you are trying to solve.

How can 1313a5e, which fixes misakes made in c2f62a3, come before
that commit in the first place?

One scenario is something like this:

 Start with a clean HEAD (always a good idea :) )
 hack hack hack
 make multiple commits
 realize that a hunk you committed in an early patch belongs in a later one.
 use git rebase -i to fix it.

Is that more clear?

Not really.

If you think that the author timestamp is the time the author
finished working on the commit, shouldn't the squashed result get
the timestamp when you finished squashing, not the timestamp of
either of the commits that were squashed?  Unlike "fixup" and
"reword", the change you are making is very different from any of
the original constituent commmits, and you finished working on that
change when you squashed these commits into one.  Propagating the
timestamp from the later ones sounds equally wrong for that purpose.

In any case, the intent of the author timestamp is to record the
time the author _started_ working on the change and came up with an
initial, possibly a partial, draft.  It does not record the time
when the commit was finalized.  "git commit --amend" preserves the
original timestamp, doesn't it?

In your example:

 pick 07bc3c9 Good commit.
 pick 1313a5e Commit to fixup into c2f62a3.
 pick c2f62a3 Another commit.

you can view 1313a5e as a "preparatory clean-up for the real change
in c2f62a3", which could be a separate commit in the final history.
If you choose to squash them together into one, the time you
recorded 1313a5e was when you started working on the combined
change, so it does not sound so wrong to take that author timestamp
for the result.