# Feature request: Allow to update commit ID in messages when rebasing 7 messages from 2019-04-17 to 2019-04-19. Participants: Giuseppe Crinò, Ævar Arnfjörð Bjarmason, Junio C Hamano, Jakub Narebski, Phil Hord. Thread: https://gitlist.dev/t/50946 ## Giuseppe Crinò, 2019-04-17 20:35 Subject: Feature request: Allow to update commit ID in messages when rebasing Message-ID: URL: https://gitlist.dev/e/CAGV3M54XhRMDXdhbfTon5nRV59VOjw8W4YrNP63TqPYm8pxd8Q%40mail.gmail.com ``` 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 ``` ## Ævar Arnfjörð Bjarmason, 2019-04-17 20:56 Subject: Re: Feature request: Allow to update commit ID in messages when rebasing Message-ID: <878sw8bbby.fsf@evledraar.gmail.com> URL: https://gitlist.dev/e/878sw8bbby.fsf%40evledraar.gmail.com In-Reply-To: ``` 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/ ``` ## Junio C Hamano, 2019-04-18 02:08 Subject: Re: Feature request: Allow to update commit ID in messages when rebasing Message-ID: URL: https://gitlist.dev/e/xmqqtvewgj4c.fsf%40gitster-ct.c.googlers.com In-Reply-To: <878sw8bbby.fsf@evledraar.gmail.com> ``` Ævar Arnfjörð Bjarmason 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. ``` ## Jakub Narebski, 2019-04-18 17:32 Subject: Re: Feature request: Allow to update commit ID in messages when rebasing Message-ID: <86o953z0b9.fsf@gmail.com> URL: https://gitlist.dev/e/86o953z0b9.fsf%40gmail.com In-Reply-To: ``` Junio C Hamano writes: > Ævar Arnfjörð Bjarmason 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 ``` ## Phil Hord, 2019-04-18 18:00 Subject: Re: Feature request: Allow to update commit ID in messages when rebasing Message-ID: URL: https://gitlist.dev/e/CABURp0r_0pTY9JAsphm-TUBVCarK8h8SmO-v8zf7OPzf%2B7%3DSJw%40mail.gmail.com In-Reply-To: <86o953z0b9.fsf@gmail.com> ``` 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 wrote: > > Junio C Hamano writes: > > Ævar Arnfjörð Bjarmason 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 ``` ## Giuseppe Crinò, 2019-04-18 17:58 Subject: Re: Feature request: Allow to update commit ID in messages when rebasing Message-ID: URL: https://gitlist.dev/e/CAGV3M55di4Nc_x25RoT0%3DdREkeCVc5_LpNabEjVDF%2BmSHK%2B0nQ%40mail.gmail.com In-Reply-To: <86o953z0b9.fsf@gmail.com> ``` On Thu, Apr 18, 2019 at 7:32 PM Jakub Narebski 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? ``` ## Jakub Narebski, 2019-04-19 10:44 Subject: Re: Feature request: Allow to update commit ID in messages when rebasing Message-ID: <86imvaz33v.fsf@gmail.com> URL: https://gitlist.dev/e/86imvaz33v.fsf%40gmail.com In-Reply-To: ``` Hello, Giuseppe Crinò writes: > On Thu, Apr 18, 2019 at 7:32 PM Jakub Narebski 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 ```