git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
* `git merge --abort` does not run `git rerere clear`
@ 2018-06-12 19:32 Sam Kuper
  2018-06-12 19:52 ` Junio C Hamano
  0 siblings, 1 reply; 3+ messages in thread
From: Sam Kuper @ 2018-06-12 19:32 UTC (permalink / raw)
  To: git

`man git-rerere` says:

> clear
>
> Reset the metadata used by rerere if a merge resolution is to be
> aborted. Calling git am [--skip|--abort] or git rebase
> [--skip|--abort] will automatically invoke this command.

It makes sense that `git am [--skip|--abort]` and `git rebase
[--skip|--abort]` would run `git rerere clear`.

However, if they run it, then shouldn't `git merge --abort` run it, too?

If not, then what is the reason why not, and might it be helpful for
this reason to be mentioned at some appropriate place in the
documentation?

Thanks :)

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

* Re: `git merge --abort` does not run `git rerere clear`
  2018-06-12 19:32 `git merge --abort` does not run `git rerere clear` Sam Kuper
@ 2018-06-12 19:52 ` Junio C Hamano
  2018-06-12 22:35   ` Sam Kuper
  0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2018-06-12 19:52 UTC (permalink / raw)
  To: Sam Kuper; +Cc: git

Sam Kuper <sam.kuper@uclmail.net> writes:

> `man git-rerere` says:
>
>> clear
>>
>> Reset the metadata used by rerere if a merge resolution is to be
>> aborted. Calling git am [--skip|--abort] or git rebase
>> [--skip|--abort] will automatically invoke this command.
>
> It makes sense that `git am [--skip|--abort]` and `git rebase
> [--skip|--abort]` would run `git rerere clear`.
>
> However, if they run it, then shouldn't `git merge --abort` run it, too?
>
> If not, then what is the reason why not, and might it be helpful for
> this reason to be mentioned at some appropriate place in the
> documentation?

I do not think there was any reason, other than that those who added
"git merge --abort" weren't as careful as they should have been ;-)

The command is a mere synonym to "git reset --merge"; I am not so
confident that "git reset --merge" should also clear the current
rerere state.  If (and this is a big if) "git reset --merge" should,
probably the right place to do so would be remove_branch_state(),
before the function removes merge_rr file.  Doing so might allow us
to lose calls to rerere_clear() individual codepaths of various
"abort" implementations make, but that would certainly require
careful thinking to avoid unintended regressions.



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

* Re: `git merge --abort` does not run `git rerere clear`
  2018-06-12 19:52 ` Junio C Hamano
@ 2018-06-12 22:35   ` Sam Kuper
  0 siblings, 0 replies; 3+ messages in thread
From: Sam Kuper @ 2018-06-12 22:35 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On 12/06/2018, Junio C Hamano <gitster@pobox.com> wrote:
> Sam Kuper <sam.kuper@uclmail.net> writes:
>> [...] It makes sense that `git am [--skip|--abort]` and `git rebase
>> [--skip|--abort]` would run `git rerere clear`.
>>
>> However, if they run it, then shouldn't `git merge --abort` run it, too?
>>
>> If not, then what is the reason why not [...]
>
> I do not think there was any reason, other than that those who added
> "git merge --abort" weren't as careful as they should have been ;-)

Thanks, good to know.

> The command is a mere synonym to "git reset --merge";

Indeed it seems so. Thank you for pointing this out.

> I am not so
> confident that "git reset --merge" should also clear the current
> rerere state.  If (and this is a big if) "git reset --merge" should,
> probably the right place to do so would be remove_branch_state(),
> before the function removes merge_rr file.

Unfortunately, I am still not familiar enough with the Git codebase to
be able to express an informed opinion about this. Sorry :(

> Doing so might allow us
> to lose calls to rerere_clear() individual codepaths of various
> "abort" implementations make,

That, I think, was an example of a garden path sentence.[1] Took me
more than one parse to understand it :)

Anyhow, yes, I agree that this might be an opportunity to DRY the
codebase in that regard. (And this would be a good thing, if so.)

> but that would certainly require
> careful thinking to avoid unintended regressions.

I don't use `git reset --merge` often enough to have formed an opinion
about whether there are any use-cases for it in which it would be
inappropriate for it to run `git rerere clear`. Apologies again not to
be able to be more helpful. I hope that you or others on the list will
be able to consider this matter, and the question of how/where to best
implement the change.

Thank you for your work maintaining Git!

[1] https://en.wikipedia.org/wiki/Garden_path_sentence

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

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-12 19:32 `git merge --abort` does not run `git rerere clear` Sam Kuper
2018-06-12 19:52 ` Junio C Hamano
2018-06-12 22:35   ` Sam Kuper

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox