* 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: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
* 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
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 public 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).