Peter Krefting <[email protected]> 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.
