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

Re: [RFC/WIP PATCH 1/1] merge-recursive: make file/directory conflicts easier to resolve

From
Elijah Newren <newren@gmail.com>
Date
Aug 9, 2018, 19:26 UTC
Message-ID
<CABPp-BH8oiJ17K6OHCikAxk8Jy9M7mSA=WCVX9KosTC+p4rE4w@mail.gmail.com>
In-Reply-To
<xmqqbmabcuhf.fsf@gitster-ct.c.googlers.com>
On Thu, Aug 9, 2018 at 10:36 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 14 quoted lines
> Elijah Newren <newren@gmail.com> writes:
>
> > File/directory conflicts are somewhat difficult to resolve; by way of
> > contrast, renames are much easier to handle.  For file/directory
> > conflicts, we already have to record the file under a different name in
> > the working copy due to the directory being in the way; if we also record
> > the file under a different name in the index then it simplifies matters
> > for the user, and ensures that 'git reset --hard' and 'git merge --abort'
> > will clean up files created by the merge operation.
>
> Yeah, and then our file "path" renamed to "path~2" to make room for
> directory "path" they introduced, can be relocated to its final
> place in the merge resolution, e.g. "git mv path~2 path/ours" or
> "git mv path path.theirs && git mv path~2 path".
Yes.  :-)
> Of course, "git rm" and "git mv" must work sensibly, if we want this
> change to be truly helpful--but if not, they need to be fixed ;-)

That actually brings up an interesting question. Right now, if given a path that appears in the index but at a stage greater than 0, git mv will fail with "not under version control". Obviously, that error message is a lie in such a case, but what should it do? Print a more accurate error message ("Refusing to rename file until you remove conflicts and git add it"?) Or, what I'd prefer, rename the entry (or entries) and keep the higher stage number(s) -- is there an unseen danger with doing this?

(Alternatively, if there is only one entry with stage greater than 0 and it has no other conflicts, one could envision git mv doing the rename and dropping to stage 0 at the same time, but that sounds a bit dangerous to me.)

Previous: Junio C HamanoNext: Junio C Hamano
Message 5 of 13 in “Two RFC/WIP series for facilitating merge conflict resolution”
  1. Elijah NewrenAug 6, 2018
  2. 0/1 Simplify handling of directory/file conflictsElijah Newren, Aug 6, 2018
  3. 1/1 merge-recursive: make file/directory conflicts easier to resolveElijah Newren, Aug 6, 2018
  4. Junio C HamanoAug 9, 2018
  5. Elijah NewrenAug 9, 2018
  6. Junio C HamanoAug 9, 2018
  7. Elijah NewrenAug 9, 2018
  8. 0/3 Modifications to handling of non-textual file merge conflictsElijah Newren, Aug 6, 2018
  9. 3/3 merge-recursive: provide more conflict hints for non-textual conflictsElijah Newren, Aug 6, 2018
  10. 2/3 merge-recursive: fix handling of submodules in modify/delete conflictsElijah Newren, Aug 6, 2018
  11. 1/3 rerere: avoid buffer overrunElijah Newren, Aug 6, 2018
  12. Junio C HamanoAug 9, 2018
  13. Elijah NewrenAug 9, 2018

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.