On 07/05/2019 05:19, Junio C Hamano wrote:
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 cha
Yes, exactly. When squashing or fixup-ing commits via rebase I really
want "git log" to show the date and time of the rebase operation and
not the date and time of the commit I rebased onto, which could be
months or even years in the past. I once worked on a project where
part of the code-base hadn
Junio C Hamano:
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
Indeed. My last command in the chain is usually
git commit --amend --date=now
to set the co
Peter Krefting 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
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 y
Jeff Schwartz writes:
> 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
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?
-
*Jeff*
7 matches
Mail list logo
