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

Re: rerere affects handling of git-stash-pop merge conflicts

From
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Date
Jul 16, 2011, 02:19 UTC
Message-ID
<alpine.DEB.2.00.1107152208530.12060@debian>
In-Reply-To
<4E1F22DF.7060209@cisco.com>
On Thu, 14 Jul 2011, Phil Hord wrote:
> Summary:
> After a 'git stash pop' with conflicts, 'git mergetool' fails to notice
> the conflicted files if 'rerere.enabled=true'.  git mergetool
> erroneously reports 'no files need merging'.

It seems to be because git-stash uses git merge-recursive directly instead of calling git merge. I don't know why git merge-recursive is used directly. It has been like that ever since git-stash was introduced in f2c66ed (Add git-stash script, 2007-06-30).

Previous: Phil HordNext: Junio C Hamano
Message 4 of 6 in “rerere affects handling of git-stash-pop merge conflicts”
  1. Phil HordJul 14, 2011
  2. Phil HordJul 15, 2011
  3. Add two basic tests for "rerere remaining"Phil Hord, Jul 15, 2011
  4. Martin von ZweigbergkJul 16, 2011
  5. Junio C HamanoJul 17, 2011
  6. Add two basic tests for "rerere remaining"Phil Hord, Jul 25, 2011

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.