Re: rerere affects handling of git-stash-pop merge conflicts
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 17, 2011, 21:59 UTC
- Message-ID
- <7voc0szhzn.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <alpine.DEB.2.00.1107152208530.12060@debian>
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
Show 11 quoted lines
> 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).
But "stash pop/apply" should never call "merge" directly, as it is not interested in creating (nor preparing to create, with "merge --no-commit") a new merge commit, nor doing the history level three-way merge.
Calling merge-recursive backend is used as a way to run a three-way tree merge with explicitly specified three trees.