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.

On Sun, Jan 20, 2013 at 12:23:41PM -0800, Junio C Hamano wrote:

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?

And we have "--reset-author" if you want to do that. It seems like just
doing "git commit --amend --reset-author" at the end[1] would solve the
original problem.  Perhaps that is something that we could better
support directly from the instruction sheet.

-Peff

[1] or after an "edit" break in the instruction sheet, if it is in the
    middle of a set of commits

Junio C Hamano wrote:

Stephen Kelly [off-list ref] writes:

quoted

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.

I think there are other scenarios, but I guess this won't happen anyway.

Thanks,

Steve.