Stephen Kelly <steveire@xxxxxxxxx> writes: > Junio C Hamano wrote: >> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html