using oldest date when squashing commits

using oldest date when squashing commits

[Oswald Buddenhagen]

moin,

during interactive rebasing, i sometimes find it necessary to move a 
hunk from one commit to a later one in the branch. now, if that hunk 
cannot be re-ordered with the later commit due to conflicting with it, 
it becomes necessary to squash the later commit onto a temporary commit 
created from the extracted hunk, not the other way around (or using a 
stash). unfortunately, this causes the author date of the later commit 
to be reset, which can rather seriously falsify the date if the branch 
is long-lived.

i know how to manually work around that, but that's not exactly user 
friendly.

my first thought was to create an --oldest-date option (essentially 
complementary to --ignore-date).

but i wonder whether it even needs to be an option? why would anyone not 
want that behavior, unless they are explicitly resetting the date 
anyway?

thanks

Re: using oldest date when squashing commits

[Johannes Sixt]

Am 19.03.22 um 13:48 schrieb Oswald Buddenhagen:
> during interactive rebasing, i sometimes find it necessary to move a
> hunk from one commit to a later one in the branch. now, if that hunk
> cannot be re-ordered with the later commit due to conflicting with it,
> it becomes necessary to squash the later commit onto a temporary commit
> created from the extracted hunk, not the other way around (or using a
> stash). unfortunately, this causes the author date of the later commit
> to be reset, which can rather seriously falsify the date if the branch
> is long-lived.

You want `fixup -C` in the todo-list. See the hints near the end of the
todo-list.

-- Hannes

Re: using oldest date when squashing commits

[Oswald Buddenhagen]

On Sun, Mar 20, 2022 at 09:05:45AM +0100, Johannes Sixt wrote:
>You want `fixup -C` in the todo-list. See the hints near the end of the
>todo-list.
>
oh, cool, thanks. i didn't expect to find it _there_. :}

note that neither the man page nor the inline comment mention either 
"date" or "timestamp". of course that seems redundant when one knows how 
commit -C works, but it's not helpful for discoverability by keywords.

Re: using oldest date when squashing commits

[Phillip Wood]

On 20/03/2022 08:05, Johannes Sixt wrote:
> Am 19.03.22 um 13:48 schrieb Oswald Buddenhagen:
>> during interactive rebasing, i sometimes find it necessary to move a
>> hunk from one commit to a later one in the branch. now, if that hunk
>> cannot be re-ordered with the later commit due to conflicting with it,
>> it becomes necessary to squash the later commit onto a temporary commit
>> created from the extracted hunk, not the other way around (or using a
>> stash). unfortunately, this causes the author date of the later commit
>> to be reset, which can rather seriously falsify the date if the branch
>> is long-lived.
> 
> You want `fixup -C` in the todo-list. See the hints near the end of the
> todo-list.

Unfortunately "fixup -C" only copies the commit message not the 
authorship (that's usually a good thing but not it means it wont work 
for what Oswald wants to do). Maybe we should add another flag for 
fixup/squash commands to take the authorship from that commit. In the 
meantime creating the temporary commit with "git commit -C" is probably 
the easiest way to keep the original authorship.

Best Wishes

Phillip

Re: using oldest date when squashing commits

[Oswald Buddenhagen]

On Tue, Oct 24, 2023 at 10:26:29AM +0100, Phillip Wood wrote:
>On 20/03/2022 08:05, Johannes Sixt wrote:
>> Am 19.03.22 um 13:48 schrieb Oswald Buddenhagen:
>>> during interactive rebasing, i sometimes find it necessary to move a
>>> hunk from one commit to a later one in the branch. now, if that hunk
>>> cannot be re-ordered with the later commit due to conflicting with it,
>>> it becomes necessary to squash the later commit onto a temporary commit
>>> created from the extracted hunk, not the other way around (or using a
>>> stash). unfortunately, this causes the author date of the later commit
>>> to be reset, which can rather seriously falsify the date if the branch
>>> is long-lived.
>> 
>> You want `fixup -C` in the todo-list. See the hints near the end of the
>> todo-list.
>
>Unfortunately "fixup -C" only copies the commit message not the 
>authorship

>(that's usually a good thing
>
why? what would that be useful for? it seems rather counter-intuitive.
it's also inconsistent with commit -c/-C's behavior, which seems like a 
red flag to me.

>but not it means it wont work for what Oswald wants to do).

>Maybe we should add another flag for fixup/squash commands to take the 
>authorship from that commit.
>
that's a possibility. but given the above, it might be better to simply 
change the behavior of -c/-C to keep the UI lean and consistent with 
commit's behavior.

regards

Re: using oldest date when squashing commits

[Phillip Wood]

On 24/10/2023 11:18, Oswald Buddenhagen wrote:
> On Tue, Oct 24, 2023 at 10:26:29AM +0100, Phillip Wood wrote:
>> On 20/03/2022 08:05, Johannes Sixt wrote:
>>> Am 19.03.22 um 13:48 schrieb Oswald Buddenhagen:
>>>> during interactive rebasing, i sometimes find it necessary to move a
>>>> hunk from one commit to a later one in the branch. now, if that hunk
>>>> cannot be re-ordered with the later commit due to conflicting with it,
>>>> it becomes necessary to squash the later commit onto a temporary commit
>>>> created from the extracted hunk, not the other way around (or using a
>>>> stash). unfortunately, this causes the author date of the later commit
>>>> to be reset, which can rather seriously falsify the date if the branch
>>>> is long-lived.
>>>
>>> You want `fixup -C` in the todo-list. See the hints near the end of the
>>> todo-list.
>>
>> Unfortunately "fixup -C" only copies the commit message not the 
>> authorship
> 
>> (that's usually a good thing
>>
> why? what would that be useful for?
 > it seems rather counter-intuitive.

In the same way that you do not want to change the author date when 
using a fixup to move a small hunk from one commit to another most users 
do not want to update the author information when they make a small 
change to a commit message using "fixup -C"

> it's also inconsistent with commit -c/-C's behavior, which seems like a 
> red flag to me.

That could mean the option is mis-named instead rather than the behavior 
being wrong.

>> but not it means it wont work for what Oswald wants to do).
> 
>> Maybe we should add another flag for fixup/squash commands to take the 
>> authorship from that commit.
>>
> that's a possibility. but given the above, it might be better to simply 
> change the behavior of -c/-C to keep the UI lean and consistent with 
> commit's behavior.

"fixup -c/-C" were conceived as a way to reword a commit message at the 
same time as optionally fixing up the commit's content. I think changing 
the behavior to automatically update the authorship would surprise 
people and as I said above most of the time one does not want that behavior.

Best Wishes

Phillip

Re: using oldest date when squashing commits

[Junio C Hamano]

Phillip Wood <phillip.wood123@gmail.com> writes:

>>> Unfortunately "fixup -C" only copies the commit message not the
>>> authorship
>> 
>>> (that's usually a good thing
>>>
>> why? what would that be useful for?
>> it seems rather counter-intuitive.
>
> In the same way that you do not want to change the author date when
> using a fixup to move a small hunk from one commit to another most
> users do not want to update the author information when they make a
> small change to a commit message using "fixup -C"

Exactly.

It would be OK to add "fixup -c --reset-author", but the default
should stay.  In addition, I wouldn't be able to use "rebase -i" to
make typofixes to commits made out of received patches if the
operation changes the authorship.

> "fixup -c/-C" were conceived as a way to reword a commit message at
> the same time as optionally fixing up the commit's content.

Yup, it still is a "fix", meaning the identity and the spirit of the
commit being fixed are unchanged.  What it aims to achieve, how it
implements the behaviour it wants to give its users, who thought of
that change, all that are the same as the original.  It may be a
nice addition to optionally allow users to use --reset-author (or
better yet, --author="Na Me <a@dd.re.ss>") with "fixup", but if the
"-c" variant can be concluded with "commit --amend --reset-author"
to achieve the same effect, that may be sufficient.

Thanks.

Re: using oldest date when squashing commits

[Oswald Buddenhagen]

On Tue, Oct 24, 2023 at 10:30:01AM -0700, Junio C Hamano wrote:
>Phillip Wood <phillip.wood123@gmail.com> writes:
>>>> Unfortunately "fixup -C" only copies the commit message not the
>>>> authorship
>>> 
>>>> (that's usually a good thing
>>>>
>>> why? what would that be useful for?
>>> it seems rather counter-intuitive.
>>
>> In the same way that you do not want to change the author date when
>> using a fixup to move a small hunk from one commit to another most
>> users do not want to update the author information when they make a
>> small change to a commit message using "fixup -C"
>
>Exactly. [...]
>I wouldn't be able to use "rebase -i" to
>make typofixes to commits made out of received patches if the
>operation changes the authorship.
>
>> "fixup -c/-C" were conceived as a way to reword a commit message at
>> the same time as optionally fixing up the commit's content.
>
>Yup, it still is a "fix", meaning the identity and the spirit of the
>commit being fixed are unchanged.  What it aims to achieve, how it
>implements the behaviour it wants to give its users, who thought of
>that change, all that are the same as the original.
>
ok, i think i finally got it. it would have never ocurred to me to make 
a command for that - i just use "squash" and throw away the extra lines.  
but i guess it sort of makes sense if you use rebase as a 
non-interactive execution backend for instructions that are fully 
determined long in advance by heaping commits at the end.

> It may be a nice addition to optionally allow users to use 
> --reset-author (or better yet, --author="Na Me <a@dd.re.ss>") with 
> "fixup"
>
that's kind of the opposite of what i'd want - the "pre-fixup" commit 
already has the equivalent of that by virtue of being fresh. so it would 
be more like --copy-author. but i'd go with adding -ca/-CA variants 
instead, for brevity.

>but if the "-c" variant can be concluded with "commit --amend 
>--reset-author" to achieve the same effect, that may be sufficient.
>
from the above follows that the equivalent of my original request would 
be appending "exec git commit --amend -C <orig>" to the "pick 
<pre-fixup>" + "fixup <orig>" commands. which is of course horrible, and 
i'd never remember to actually do that. it will be hard enough to 
retrain myself to use -CA instead of -C.

regards

Re: using oldest date when squashing commits

[Johannes Sixt]

Am 24.10.23 um 19:30 schrieb Junio C Hamano:
> Phillip Wood <phillip.wood123@gmail.com> writes:
>> "fixup -c/-C" were conceived as a way to reword a commit message at
>> the same time as optionally fixing up the commit's content.
> 
> Yup, it still is a "fix", meaning the identity and the spirit of the
> commit being fixed are unchanged.

That's a pitty, because that is not at all what *I* use "fixup -C" for.
To update the commit message, I use "squash" (or occasionally "reword").
I use "fixup -C" after the following events:

1. Commit unfinished changes for whatever reason. Usually the commit
message just says "WIP <topic>" because that's what it is.
2. Make a fixup commit for an earlier commit because doing the fixup now
gets it out of the way, and often delaying it until after the completed
change would cause merge conflicts.
3. Complete the WIP including the commit message.

I would now use "fixup -C" on commit 3, because its metadata reflects
reality more accurately than that of 1. Commit 3 often comes days after 1.

-- Hannes

Re: using oldest date when squashing commits

[Marc Branchaud]

On 2023-10-24 17:19, Johannes Sixt wrote:
> Am 24.10.23 um 19:30 schrieb Junio C Hamano:
>> Phillip Wood <phillip.wood123@gmail.com> writes:
>>> "fixup -c/-C" were conceived as a way to reword a commit message at
>>> the same time as optionally fixing up the commit's content.
>>
>> Yup, it still is a "fix", meaning the identity and the spirit of the
>> commit being fixed are unchanged.
> 
> That's a pitty, because that is not at all what *I* use "fixup -C" for.
> To update the commit message, I use "squash" (or occasionally "reword").
> I use "fixup -C" after the following events:
> 
> 1. Commit unfinished changes for whatever reason. Usually the commit
> message just says "WIP <topic>" because that's what it is.
> 2. Make a fixup commit for an earlier commit because doing the fixup now
> gets it out of the way, and often delaying it until after the completed
> change would cause merge conflicts.
> 3. Complete the WIP including the commit message.
> 
> I would now use "fixup -C" on commit 3, because its metadata reflects
> reality more accurately than that of 1. Commit 3 often comes days after 1.

Speaking of the metadata ...

I never use "fixup -C" (or -c), but I do use squash/fixup a lot.  I find 
that I would prefer it if Git used the most recent Author date from the 
set of commits being combined, rather than preserving the picked 
commit's Author date.  Sometimes it takes quite a while for me to get a 
piece of work sorted out, and I would rather have the Author date in the 
end-result commit reflect the work's completion time than its initiation 
time.

The current behaviour means that when scanning through commits with 
tools like gitk (which shows just the Author date in its list of 
commits) I'll often see what I feel are inaccurate or confusing dates 
there, and I use the Committer date (a bit less convenient in gitk) to 
figure out when the work was actually "done".  (Although the span 
between the Author date from the start of the work and the Committer 
date from the end of the work would roughly reflect how long the work 
took to complete, I don't use Git for that kind of information.)

Anyway, this is a minor itch for me that I've never felt the need to 
scratch.  I just thought I'd mention it since the topic is being discussed.

		M.

Re: using oldest date when squashing commits

[Oswald Buddenhagen]

On Fri, Oct 27, 2023 at 08:34:40AM -0400, Marc Branchaud wrote:
>I never use "fixup -C" (or -c), but I do use squash/fixup a lot.  I 
>find that I would prefer it if Git used the most recent Author date 
>from the set of commits being combined, rather than preserving the 
>picked commit's Author date.
>
that would be unreliable, as plain amends wouldn't be reflected. that 
may be rare in your workflow, but still.

>Sometimes it takes quite a while for me to get a piece of work sorted 
>out, and I would rather have the Author date in the end-result commit 
>reflect the work's completion time than its initiation time.
>
afaict, you need to get used to `--amend --reset-author` all commits 
before you push to achieve this reliably. that can be easily automated 
by using -x with rebase -i (filter-repo (ex filter-branch) would also 
work).

regards

Re: using oldest date when squashing commits

[Marc Branchaud]

On 2023-10-27 08:45, Oswald Buddenhagen wrote:
> On Fri, Oct 27, 2023 at 08:34:40AM -0400, Marc Branchaud wrote:
>> I never use "fixup -C" (or -c), but I do use squash/fixup a lot.  I 
>> find that I would prefer it if Git used the most recent Author date 
>> from the set of commits being combined, rather than preserving the 
>> picked commit's Author date.
>>
> that would be unreliable, as plain amends wouldn't be reflected. that 
> may be rare in your workflow, but still.

I'm not talking about amends, plain or otherwise.  I'm talking about 
fixup/squash.

(Why do you focus so much an making rebase and commit behave 
identically?  There is no reason to do so just because they happen to 
share a couple of parameter names.)

>> Sometimes it takes quite a while for me to get a piece of work sorted 
>> out, and I would rather have the Author date in the end-result commit 
>> reflect the work's completion time than its initiation time.
>>
> afaict, you need to get used to `--amend --reset-author` all commits 
> before you push to achieve this reliably. that can be easily automated 
> by using -x with rebase -i (filter-repo (ex filter-branch) would also 
> work).

Yes, I know how to force my desired author date on commits, thanks.

		M.

Re: using oldest date when squashing commits

[Oswald Buddenhagen]

On Fri, Oct 27, 2023 at 09:20:04AM -0400, Marc Branchaud wrote:
>
>On 2023-10-27 08:45, Oswald Buddenhagen wrote:
>> On Fri, Oct 27, 2023 at 08:34:40AM -0400, Marc Branchaud wrote:
>>> I never use "fixup -C" (or -c), but I do use squash/fixup a lot.  I 
>>> find that I would prefer it if Git used the most recent Author date 
>>> from the set of commits being combined, rather than preserving the 
>>> picked commit's Author date.
>>>
>> that would be unreliable, as plain amends wouldn't be reflected. that 
>> may be rare in your workflow, but still.
>
>I'm not talking about amends, plain or otherwise.
>
but why wouldn't you? your use case of marking the date of completion 
naturally covers all ways of amending commits, whether directly or via 
squashing.

regards

Re: using oldest date when squashing commits

[Marc Branchaud]

On 2023-10-27 09:26, Oswald Buddenhagen wrote:
> On Fri, Oct 27, 2023 at 09:20:04AM -0400, Marc Branchaud wrote:
>>
>> On 2023-10-27 08:45, Oswald Buddenhagen wrote:
>>> On Fri, Oct 27, 2023 at 08:34:40AM -0400, Marc Branchaud wrote:
>>>> I never use "fixup -C" (or -c), but I do use squash/fixup a lot.  I 
>>>> find that I would prefer it if Git used the most recent Author date 
>>>> from the set of commits being combined, rather than preserving the 
>>>> picked commit's Author date.
>>>>
>>> that would be unreliable, as plain amends wouldn't be reflected. that 
>>> may be rare in your workflow, but still.
>>
>> I'm not talking about amends, plain or otherwise.
>>
> but why wouldn't you? your use case of marking the date of completion 
> naturally covers all ways of amending commits, whether directly or via 
> squashing.

Please do not presume what my use cases might be.  I'm quite happy with 
commit's behaviour, but not happy with rebase's fixup/squash behaviour 
because it's too much work to achieve the desired results.  (Results 
which, as I said, I don't care about enough to bother changing anyway).

		M.

Re: using oldest date when squashing commits

[Junio C Hamano]

Marc Branchaud <marcnarc@xiplink.com> writes:

> I never use "fixup -C" (or -c), but I do use squash/fixup a lot.  I
> find that I would prefer it if Git used the most recent Author date
> from the set of commits being combined, rather than preserving the
> picked commit's Author date.  Sometimes it takes quite a while for me
> to get a piece of work sorted out, and I would rather have the Author
> date in the end-result commit reflect the work's completion time than
> its initiation time.

Yeah, I can sympathize but with both positions, as I can see why
most people would want "minor fixups and typofixes" to retain the
original authorship date, and when concluding a "combining the whole
steps together to reach this final single patch" development, they
would want to record the completion date.  The "take the one's
authorship and apply only the effects and not metadata from the
fixups" is a good match for the former.  To support the latter, we
can just ignore the timestamp of any commits that were involved in
the end result, and record the time "rebase -i" was concluded
instead, but the tool is not set up for doing so.

> The current behaviour means that when scanning through commits with
> tools like gitk (which shows just the Author date in its list of
> commits) I'll often see what I feel are inaccurate or confusing dates
> there,...

Yup, exactly.  Two opposing worldviews, which is not even per-user,
but depends on why the "fixup/squash" was used, exists, but the tool
was designed to support the "small fixup for work that was mostly
done already" use case, so the other usecase is left for people to
say "Yes, I know how to force my desired author date on commits,
thanks." ;-)

> Anyway, this is a minor itch for me that I've never felt the need to
> scratch.  I just thought I'd mention it since the topic is being
> discussed.

Yup, it is a very good observation.  Giving it a good UI to support
both worldviews would be a good exercise, as we all need both
behaviour from time to time.

Thanks.