Feature request: Allow to update commit ID in messages when rebasing

Feature request: Allow to update commit ID in messages when rebasing

[Giuseppe Crinò]

The feature I'm asking is to add an extra-step during rebasing,
checking whether there's a reference to a commit that's not going to
be included in history and asks the user whether the heuristics is
correct and if she wants to update those references.

Scenario: it can happen for a commit message to contain the ID of an
ancestor commit. A typical example is a commit with the message
"revert 01a9fe8". If 01a9fe8 and the commit that reverts it are
involved in a rebase the message "revert 01a9fe8" is no longer valid
-- the old 01a9fe8 has now a different hash. This will most likely be
ignored by the person who's rebasing but will let the other people
reading history confused.

Giuseppe

Re: Feature request: Allow to update commit ID in messages when rebasing

[Ævar Arnfjörð Bjarmason]

On Wed, Apr 17 2019, Giuseppe Crinò wrote:

> The feature I'm asking is to add an extra-step during rebasing,
> checking whether there's a reference to a commit that's not going to
> be included in history and asks the user whether the heuristics is
> correct and if she wants to update those references.
>
> Scenario: it can happen for a commit message to contain the ID of an
> ancestor commit. A typical example is a commit with the message
> "revert 01a9fe8". If 01a9fe8 and the commit that reverts it are
> involved in a rebase the message "revert 01a9fe8" is no longer valid
> -- the old 01a9fe8 has now a different hash. This will most likely be
> ignored by the person who's rebasing but will let the other people
> reading history confused.

This would be useful. Done properly we'd need some machinery/command to
extract the commit id parts from the free-text of the commit
message. That would be useful for other parts of git, e.g. as discussed
here:
https://public-inbox.org/git/xmqqvaxp9oyp.fsf@gitster.mtv.corp.google.com/

Re: Feature request: Allow to update commit ID in messages when rebasing

[Junio C Hamano]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Wed, Apr 17 2019, Giuseppe Crinò wrote:
>
>> The feature I'm asking is to add an extra-step during rebasing,
>> checking whether there's a reference to a commit that's not going to
>> be included in history and asks the user whether the heuristics is
>> correct and if she wants to update those references.
>>
>> Scenario: it can happen for a commit message to contain the ID of an
>> ancestor commit. A typical example is a commit with the message
>> "revert 01a9fe8". If 01a9fe8 and the commit that reverts it are
>> involved in a rebase the message "revert 01a9fe8" is no longer valid
>> -- the old 01a9fe8 has now a different hash. This will most likely be
>> ignored by the person who's rebasing but will let the other people
>> reading history confused.
>
> This would be useful. Done properly we'd need some machinery/command to
> extract the commit id parts from the free-text of the commit
> message. That would be useful for other parts of git, e.g. as discussed
> here:
> https://public-inbox.org/git/xmqqvaxp9oyp.fsf@gitster.mtv.corp.google.com/

That's a helpful input.

But in general we do not have an infrastructure to systematically
keep track of "this commit was rewritten to produce that other
commit", so even if a mention of an old/superseded commit can be
identified reliably, there is no reliable source to rewrite it to
the name of the corresponding commit in the new world.

For that mapping, we'd need something like the "git change/evolve"
Stefan Xenos was working on, which hasn't materialized.

Re: Feature request: Allow to update commit ID in messages when rebasing

[Jakub Narebski]

Junio C Hamano <gitster@pobox.com> writes:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>> On Wed, Apr 17 2019, Giuseppe Crinò wrote:
>>
>>> The feature I'm asking is to add an extra-step during rebasing,
>>> checking whether there's a reference to a commit that's not going to
>>> be included in history and asks the user whether the heuristics is
>>> correct and if she wants to update those references.
>>>
>>> Scenario: it can happen for a commit message to contain the ID of an
>>> ancestor commit. A typical example is a commit with the message
>>> "revert 01a9fe8". If 01a9fe8 and the commit that reverts it are
>>> involved in a rebase the message "revert 01a9fe8" is no longer valid
>>> -- the old 01a9fe8 has now a different hash. This will most likely be
>>> ignored by the person who's rebasing but will let the other people
>>> reading history confused.
>>
>> This would be useful. Done properly we'd need some machinery/command to
>> extract the commit id parts from the free-text of the commit
>> message. That would be useful for other parts of git, e.g. as discussed
>> here:
>> https://public-inbox.org/git/xmqqvaxp9oyp.fsf@gitster.mtv.corp.google.com/
>
> That's a helpful input.
>
> But in general we do not have an infrastructure to systematically
> keep track of "this commit was rewritten to produce that other
> commit", so even if a mention of an old/superseded commit can be
> identified reliably, there is no reliable source to rewrite it to
> the name of the corresponding commit in the new world.
>
> For that mapping, we'd need something like the "git change/evolve"
> Stefan Xenos was working on, which hasn't materialized.

Well, what about limiting changes and rewriting only to the commits
being rewritten by [interactive] rebase?  I mean that we would rewrite
"revert 01a9fe8" only if:

a.) the commit with this message is undergoing rewrite
b.) the commit 01a9fe8 is undergoing rewrite in the same command

We could use the infrastructure from git-filter-branch for this.

It is serious limitation, but that might be good enough for Giuseppe
Crinò use case.  Though for example there is a question what to do if
referred-to commit (01a9fe8 in the example) is simply dropped, or is
gets split in two?  Ask user?


Another possibility would be to provide a command line option to rebase
which would automatically generate replacements (in git-replace meaning)
from old pre-rebase name to new post-rebase name (assuming no splitting,
no dropping commits).  This would make references just work... well, as
long as refs/replace/* are in place (they are not copied by default).

On the other hand some of our performance-improving features, like the
commit-graph, do not work if there are replacements.


Best,
--
Jakub Narębski

Re: Feature request: Allow to update commit ID in messages when rebasing

[Giuseppe Crinò]

On Thu, Apr 18, 2019 at 7:32 PM Jakub Narebski <jnareb@gmail.com> wrote:
> Well, what about limiting changes and rewriting only to the commits
> being rewritten by [interactive] rebase?  I mean that we would rewrite
> "revert 01a9fe8" only if:
>
> a.) the commit with this message is undergoing rewrite
> b.) the commit 01a9fe8 is undergoing rewrite in the same command
>
> We could use the infrastructure from git-filter-branch for this.
>
> It is serious limitation, but that might be good enough for Giuseppe
> Crinò use case.

In which case you need to change the ID of "revert 01a9fe8" _even if_
01a9fe8 is not involved in the rebase? Wouldn't be a solution to my
use-case an already complete solution?

Re: Feature request: Allow to update commit ID in messages when rebasing

[Jakub Narebski]

Hello,

Giuseppe Crinò <giuscri@gmail.com> writes:
> On Thu, Apr 18, 2019 at 7:32 PM Jakub Narebski <jnareb@gmail.com> wrote:

>> Well, what about limiting changes and rewriting only to the commits
>> being rewritten by [interactive] rebase?  I mean that we would rewrite
>> "revert 01a9fe8" only if:
>>
>> a.) the commit with this message is undergoing rewrite
>> b.) the commit 01a9fe8 is undergoing rewrite in the same command
>>
>> We could use the infrastructure from git-filter-branch for this.
>>
>> It is serious limitation, but that might be good enough for Giuseppe
>> Crinò use case.
>
> In which case you need to change the ID of "revert 01a9fe8" _even if_
> 01a9fe8 is not involved in the rebase? Wouldn't be a solution to my
> use-case an already complete solution?

What I meant by "serious limitation" is that the condition a.) might mot
hold true.  You might be rebasing / rewriting the commit 01a9fe8, but
there might be some commit not undergoing rewrite (for example one on a
separate branch) that refers to the commit being rewritten, e.g. by
including "revert 01a9fe8" in the commit message.

We also need to assume that the commit referred to (i.e. 01a9fe8) is
being rewritten earlier in sequence than referring commit (i.e. one with
"revert 01a9fe8").

Regards,
--
Jakub Narębski

Re: Feature request: Allow to update commit ID in messages when rebasing

[Phil Hord]

Wouldn't we need to extend this to cherry-pick, too?  Suppose I do this:

    $ git log -2 --oneline --decorate foo
    abcd123456  (foo)   Revert 123456aaaa
    123456aaaa  Some useful commit for the future, but not now

    $ git checkout bar
    $ git cherry-pick foo^ foo

    $ git log -2 --oneline --decorate
    badc0ffee  (bar)   Revert 123456aaaa
    babeface0  Some useful commit for the future, but not now

Now when I rebase bar, the revert appears to be untwinned.

Similar problems arise for other history modifying tools like
filter-branch, fast-export, reposurgeon, bfg, etc.

I guess we can use 'git patch-id' to see if the companion commit is
still in our history, but this seems tenuous.  Can we make it work
anyway?


On Thu, Apr 18, 2019 at 10:33 AM Jakub Narebski <jnareb@gmail.com> wrote:
>
> Junio C Hamano <gitster@pobox.com> writes:
> > Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> >> On Wed, Apr 17 2019, Giuseppe Crinò wrote:
> >>
> >>> The feature I'm asking is to add an extra-step during rebasing,
> >>> checking whether there's a reference to a commit that's not going to
> >>> be included in history and asks the user whether the heuristics is
> >>> correct and if she wants to update those references.
> >>>
> >>> Scenario: it can happen for a commit message to contain the ID of an
> >>> ancestor commit. A typical example is a commit with the message
> >>> "revert 01a9fe8". If 01a9fe8 and the commit that reverts it are
> >>> involved in a rebase the message "revert 01a9fe8" is no longer valid
> >>> -- the old 01a9fe8 has now a different hash. This will most likely be
> >>> ignored by the person who's rebasing but will let the other people
> >>> reading history confused.
> >>
> >> This would be useful. Done properly we'd need some machinery/command to
> >> extract the commit id parts from the free-text of the commit
> >> message. That would be useful for other parts of git, e.g. as discussed
> >> here:
> >> https://public-inbox.org/git/xmqqvaxp9oyp.fsf@gitster.mtv.corp.google.com/
> >
> > That's a helpful input.
> >
> > But in general we do not have an infrastructure to systematically
> > keep track of "this commit was rewritten to produce that other
> > commit", so even if a mention of an old/superseded commit can be
> > identified reliably, there is no reliable source to rewrite it to
> > the name of the corresponding commit in the new world.
> >
> > For that mapping, we'd need something like the "git change/evolve"
> > Stefan Xenos was working on, which hasn't materialized.
>
> Well, what about limiting changes and rewriting only to the commits
> being rewritten by [interactive] rebase?  I mean that we would rewrite
> "revert 01a9fe8" only if:
>
> a.) the commit with this message is undergoing rewrite
> b.) the commit 01a9fe8 is undergoing rewrite in the same command
>
> We could use the infrastructure from git-filter-branch for this.
>
> It is serious limitation, but that might be good enough for Giuseppe
> Crinò use case.  Though for example there is a question what to do if
> referred-to commit (01a9fe8 in the example) is simply dropped, or is
> gets split in two?  Ask user?
>
>
> Another possibility would be to provide a command line option to rebase
> which would automatically generate replacements (in git-replace meaning)
> from old pre-rebase name to new post-rebase name (assuming no splitting,
> no dropping commits).  This would make references just work... well, as
> long as refs/replace/* are in place (they are not copied by default).
>
> On the other hand some of our performance-improving features, like the
> commit-graph, do not work if there are replacements.
>
>
> Best,
> --
> Jakub Narębski