git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* Feature request: Allow to update commit ID in messages when rebasing
@ 2019-04-17 20:35 Giuseppe Crinò
  2019-04-17 20:56 ` Ævar Arnfjörð Bjarmason
  0 siblings, 1 reply; 7+ messages in thread
From: Giuseppe Crinò @ 2019-04-17 20:35 UTC (permalink / raw)
  To: git

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Feature request: Allow to update commit ID in messages when rebasing
  2019-04-17 20:35 Feature request: Allow to update commit ID in messages when rebasing Giuseppe Crinò
@ 2019-04-17 20:56 ` Ævar Arnfjörð Bjarmason
  2019-04-18  2:08   ` Junio C Hamano
  0 siblings, 1 reply; 7+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2019-04-17 20:56 UTC (permalink / raw)
  To: Giuseppe Crinò; +Cc: git, Junio C Hamano, Jakub Narebski


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/

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Feature request: Allow to update commit ID in messages when rebasing
  2019-04-17 20:56 ` Ævar Arnfjörð Bjarmason
@ 2019-04-18  2:08   ` Junio C Hamano
  2019-04-18 17:32     ` Jakub Narebski
  0 siblings, 1 reply; 7+ messages in thread
From: Junio C Hamano @ 2019-04-18  2:08 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason
  Cc: Giuseppe Crinò, git, Jakub Narebski

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Feature request: Allow to update commit ID in messages when rebasing
  2019-04-18  2:08   ` Junio C Hamano
@ 2019-04-18 17:32     ` Jakub Narebski
  2019-04-18 17:58       ` Giuseppe Crinò
  2019-04-18 18:00       ` Phil Hord
  0 siblings, 2 replies; 7+ messages in thread
From: Jakub Narebski @ 2019-04-18 17:32 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Ævar Arnfjörð Bjarmason, Giuseppe Crinò, git

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Feature request: Allow to update commit ID in messages when rebasing
  2019-04-18 17:32     ` Jakub Narebski
@ 2019-04-18 17:58       ` Giuseppe Crinò
  2019-04-19 10:44         ` Jakub Narebski
  2019-04-18 18:00       ` Phil Hord
  1 sibling, 1 reply; 7+ messages in thread
From: Giuseppe Crinò @ 2019-04-18 17:58 UTC (permalink / raw)
  To: Jakub Narebski
  Cc: Junio C Hamano, Ævar Arnfjörð Bjarmason, git

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?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Feature request: Allow to update commit ID in messages when rebasing
  2019-04-18 17:32     ` Jakub Narebski
  2019-04-18 17:58       ` Giuseppe Crinò
@ 2019-04-18 18:00       ` Phil Hord
  1 sibling, 0 replies; 7+ messages in thread
From: Phil Hord @ 2019-04-18 18:00 UTC (permalink / raw)
  To: Jakub Narebski
  Cc: Junio C Hamano, Ævar Arnfjörð Bjarmason,
	Giuseppe Crinò,
	Git

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Feature request: Allow to update commit ID in messages when rebasing
  2019-04-18 17:58       ` Giuseppe Crinò
@ 2019-04-19 10:44         ` Jakub Narebski
  0 siblings, 0 replies; 7+ messages in thread
From: Jakub Narebski @ 2019-04-19 10:44 UTC (permalink / raw)
  To: Giuseppe Crinò
  Cc: Junio C Hamano, Ævar Arnfjörð Bjarmason, git

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2019-04-19 19:19 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-17 20:35 Feature request: Allow to update commit ID in messages when rebasing Giuseppe Crinò
2019-04-17 20:56 ` Ævar Arnfjörð Bjarmason
2019-04-18  2:08   ` Junio C Hamano
2019-04-18 17:32     ` Jakub Narebski
2019-04-18 17:58       ` Giuseppe Crinò
2019-04-19 10:44         ` Jakub Narebski
2019-04-18 18:00       ` Phil Hord

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).