git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled

From
Junio C Hamano <gitster@pobox.com>
Date
Jun 16, 2012, 05:19 UTC
Message-ID
<7vd34z96lv.fsf@alter.siamese.dyndns.org>
In-Reply-To
<B4036488-1ECA-41C9-BD97-B2ABD116D54C@kilzer.net>
David Kilzer <ddkilzer@kilzer.net> writes:
Show 9 quoted lines
>> The configuration rerere.enabled *never* meant that the user blindly
>> trusts the result of replaying a previous resolution.  If you were
>> checking rerere.autoupdate configuration variable, the patch may
>> have made some sense, but basing the decision on rerere.enabled
>> (which by the way is not necessary to trigger the rerere machinery
>> these days, as long as $GIT_DIR/rr-cache/ directory exists) sounds
>> very wrong.
>
> Thanks!  I'll repost the patch based on rerere.autoupdate for further discussion.

I do not use the configuration variable myself, and I didn't check the code, but if you had rerere.autoupdate set, doesn't "git merge" in the codepath you are touching (or anywhere for that matter) already blindly take the replayed resolution and commit the result?

In other words, do you need to do anything special to make the command honour rerere.autoupdate?

Assuming that your patch does not need to do anything special based on the rerere.autoupdate configuration (because the underlying "merge" may automatically take care of it), I think what you need may be a mechanism to give --[no-]rerere-autoupdate option to "git rebase -m/-i/-p" and pass that option to the invocation of underlying "git merge", so that the user who does not usually want to blindly trust the replayed resolution (hence rerere.autoupdate configured to false) can choose to tell the "git rebase -m/-i/-p" command that "for this single invocation it is OK to trust the replayed resolution". Or the other way around, i.e. "Even though I have rerere.autoupdate configured to true, for this single invocation of 'rebase', I am giving the '--no-rerere-autoupdate' option to tell you that you should _not_ blindly replay the resolution."

Hrm?
Previous: David KilzerNext: David Kilzer
Message 4 of 12 in “rebase -i -p: use rerere to resolve conflicts if enabled”
  1. rebase -i -p: use rerere to resolve conflicts if enabledDavid D. Kilzer, Jun 15, 2012
  2. Junio C HamanoJun 15, 2012
  3. David KilzerJun 16, 2012
  4. Junio C HamanoJun 16, 2012
  5. David KilzerJun 17, 2012
  6. Junio C HamanoJun 17, 2012
  7. David KilzerJun 17, 2012
  8. Johannes SixtJun 17, 2012
  9. David KilzerJun 17, 2012
  10. Johannes SixtJun 18, 2012
  11. Junio C HamanoJun 17, 2012
  12. Junio C HamanoJun 17, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.