Request to add option to interactive rebase to preserve latest commit date

Request to add option to interactive rebase to preserve latest commit date

[Jeff Schwartz]

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*

Re: Request to add option to interactive rebase to preserve latest commit date

[Junio C Hamano]

Jeff Schwartz <jefftschwartz@gmail.com> 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 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):

	$ git rebase -i HEAD~2

and tell the editor that you want to 'edit' both instead of just
'pick'ing, the command will give you control back for both of these
two commits, and you can say "git rebase --continue".


    o----X----Y (original history)
     \
      \
       X'----Y' (rebased history)

After the exercise, the two new commits that replaced the two
commits from the original history

 (1) retain their own author timestamp; and

 (2) record the time when these new commits are created as the
     committer timestamp.

So there is no "most recent" or "oldest" timestamp in the series
involved.  The author timestamp of commit X' (which corresponds to
the commit X in the original history) in the rewritten history is
the same as the author timestamp of commit X.  Same for the author
timestamps of commit Y and Y'.

The committer timestamp of commit X' and commit Y' are the actual
time each step of your "rebase -i" operation creates them, which
should be more recent than those of commit X and commit Y, unless
your clock or the clock on the machine on which X and Y were created
are not in sync with the real world.

Re: Request to add option to interactive rebase to preserve latest commit date

[Peter Krefting]

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.

-- 
\\// Peter - http://www.softwolves.pp.se/

Re: Request to add option to interactive rebase to preserve latest commit date

[Junio C Hamano]

Peter Krefting <peter@softwolves.pp.se> 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.

Re: Request to add option to interactive rebase to preserve latest commit date

[Peter Krefting]

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 commit date to now. In my use-case it is often a 
work-in-progress commit that I start out with, which I refine over a 
couple of hours/days/weeks to get working properly (depending on the 
complexity of the change), and when I am finally done, the proper 
dating of the change is "now", not "when I first started doing it".

> 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.

I'd be happy with a parameter and/or configuration variable saying 
"amend and rebase uses last commit date".

-- 
\\// Peter - http://www.softwolves.pp.se/

Re: Request to add option to interactive rebase to preserve latest commit date

[Jeff Schwartz]

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't been touched in over a year. After
performing a number of WIPs on it over a 4 month period I cleaned up
the final commit using interactive rebase, squashing all the WIPs into
a single commit whose message reflected the actual scope of the
changes that had been made. A naive project manager with limited
understanding of Git other than how to use 'git log' to oversee what
us developers have been up to time-wise was enraged that we had
committed changes months back and appeared to have done nothing since
then. I believe that by adding an option to
'rebase -i hash' that would apply the current date and time of the
operation would be an awesome addition to Git and its user base.

*Jeff*

On Tue, May 7, 2019 at 1:45 AM Peter Krefting <peter@softwolves.pp.se> wrote:
>
> 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 commit date to now. In my use-case it is often a
> work-in-progress commit that I start out with, which I refine over a
> couple of hours/days/weeks to get working properly (depending on the
> complexity of the change), and when I am finally done, the proper
> dating of the change is "now", not "when I first started doing it".
>
> > 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.
>
> I'd be happy with a parameter and/or configuration variable saying
> "amend and rebase uses last commit date".
>
> --
> \\// Peter - http://www.softwolves.pp.se/

Re: Request to add option to interactive rebase to preserve latest commit date

[Philip Oakley]

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 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,
IIUC the effective change in authorship was noted in another thread 
about a perceived problem in rebase, and it just bit me as well recently 
(and the Github PR bot rejected my series for a mismatched 
author/sign-off :-(.

If a commit is edited in a `rebase -i` then I think the same can happen, 
resulting in the same user surprise at the change. Possibly a simple 
documentation note may help reduce user surprise.
> 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.
--
Philip