Peter Krefting <peter@xxxxxxxxxxxxxxxx> writes: > Junio C Hamano: > >>> Using interactive rebase has one flaw IMHO and that is the way it >>> handles dating its commit. Can you add an option to interactive rebase >>> that would make it use the date from the commit that is most recent >>> and not the date from the commit that is the oldest? >> >> I am not sure what you mean by this. If you interactively rebase >> the topmost two commits (assuming that since three commits ago, you >> have a linear history): > > I sort of assume that this is when merging several fixup! or squash! > commits. I often end up adding lines the code to date these with the > current date, but the date of the last fixup'ed or squash'ed commit > would probably be better. Ah, I see. So if you have (time flows left to right, as usual): A---B---C where B and C are fixup for A, the question is what's the author ident and author time should be for the resulting single commit. I think we currently use the ident and time from the original A, and that is the only right thing to do, as I view $ git commit -m A $ edit $ git commit -a --fixup HEAD ;# create B to fix A $ edit $ git commit -a --fixup HEAD^ ;# create C to fix A $ git rebase --autosquash -i HEAD~3 ;# squash B and C into A as merely a different way to do the following: $ git commit -m A $ edit $ edit further ;# working tree has an equivalent of C $ git commit --amend -a The principle is "the bulk of the work was done in A, no matter what is done incrementally by squashing in or amending small refinements; the primary authorship date and time stays the same as the original". When the person who is correcting other's change with --amend makes a contribution that is substantial enough such that the amended HEAD no longer resembles the original HEAD, there is a mechanism to let the amender take authorship, i.e. do this at the last step instead $ git commit --reset-author --amend -a in the second sequence. I do not think there currently is an equivalent in "rebase -i" language to do so. I am still not convinced it is a good idea, but I can see how another verb that behaves like existing "fixup" or "squash" but use the authorship not from the updated but from the updating commit might seem useful.
