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

Re: [PATCH 2/9] merge tests: expect improved directory/file conflict handling in ort

From
Elijah Newren <newren@gmail.com>
Date
Oct 23, 2020, 17:40 UTC
Message-ID
<CABPp-BEhjecB7_juP3cSuF7MUHKbPXqAxKgKstPZw2ezHXputw@mail.gmail.com>
In-Reply-To
<9394d526f1425fcf6b8865b53b737ba81c11dd80.1603468885.git.gitgitgadget@gmail.com>

On Fri, Oct 23, 2020 at 9:01 AM Elijah Newren via GitGitGadget <gitgitgadget@gmail.com> wrote:

Show 41 quoted lines
>
> From: Elijah Newren <newren@gmail.com>
>
> merge-recursive.c is built on the idea of running unpack_trees() and
> then "doing minor touch-ups" to get the result.  Unfortunately,
> unpack_trees() was run in an update-as-it-goes mode, leading
> merge-recursive.c to follow suit and end up with an immediate evaluation
> and fix-it-up-as-you-go design.  Some things like directory/file
> conflicts are not well representable in the index data structure, and
> required special extra code to handle.  But then when it was discovered
> that rename/delete conflicts could also be involved in directory/file
> conflicts, the special directory/file conflict handling code had to be
> copied to the rename/delete codepath.  ...and then it had to be copied
> for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it
> still missed some.  Further, when it was discovered that there were also
> file/submodule conflicts and submodule/directory conflicts, we needed to
> copy the special submodule handling code to all the special cases
> throughout the codebase.
>
> And then it was discovered that our handling of directory/file conflicts
> was suboptimal because it would create untracked files to store the
> contents of the conflicting file, which would not be cleaned up if
> someone were to run a 'git merge --abort' or 'git rebase --abort'.  It
> was also difficult or scary to try to add or remove the index entries
> corresponding to these files given the directory/file conflict in the
> index.  But changing merge-recursive.c to handle these correctly was a
> royal pain because there were so many sites in the code with similar but
> not identical code for handling directory/file/submodule conflicts that
> would all need to be updated.
>
> I have worked hard to push all directory/file/submodule conflict
> handling in merge-ort through a single codepath, and avoid creating
> untracked files for storing tracked content (it does record things at
> alternate paths, but makes sure they have higher-order stages in the
> index).
>
> Since updating merge-recursive is too much work and we don't want to
> destabilize it, instead update the testsuite to have different
> expectations for relevant directory/file/submodule conflict tests.
>
> Signed-off-by: Elijah Newren <newren@gmail.com>

Perhaps I should also mention that these changes to directory/file conflict handling were discussed previously in the thread at https://lore.kernel.org/git/xmqqbmabcuhf.fsf@gitster-ct.c.googlers.com/. I just never got around to a complete implementation within merge-recursive.c, but did implement it in merge-ort.c

I still haven't gotten around to fixing up git-mv and git-rm as suggested by Junio in that thread; but at least I've finally gotten the merge machinery side written...

Previous: Elijah Newren via GitGitGadgetNext: Elijah Newren via GitGitGadget
Message 3 of 31 in “Support both merge backends in the testsuite, via environment variable”
  1. 0/9 Support both merge backends in the testsuite, via environment variableElijah Newren via GitGitGadget, Oct 23, 2020
  2. 2/9 merge tests: expect improved directory/file conflict handling in ortElijah Newren via GitGitGadget, Oct 23, 2020
  3. Elijah NewrenOct 23, 2020
  4. 3/9 t6416: correct expectation for rename/rename(1to2) + directory/fileElijah Newren via GitGitGadget, Oct 23, 2020
  5. 1/9 t/: new helper for tests that pass with ort but fail with recursiveElijah Newren via GitGitGadget, Oct 23, 2020
  6. Junio C HamanoOct 23, 2020
  7. Elijah NewrenOct 23, 2020
  8. Elijah NewrenOct 23, 2020
  9. Đoàn Trần Công DanhOct 24, 2020
  10. Elijah NewrenOct 24, 2020
  11. Đoàn Trần Công DanhOct 25, 2020
  12. Elijah NewrenOct 26, 2020
  13. Junio C HamanoOct 26, 2020
  14. 4/9 t6404, t6423: expect improved rename/delete handling in ort backendElijah Newren via GitGitGadget, Oct 23, 2020
  15. 5/9 t6423: expect improved conflict markers labels in the ort backendElijah Newren via GitGitGadget, Oct 23, 2020
  16. 6/9 merge tests: expect slight differences in output for recursive vs. ortElijah Newren via GitGitGadget, Oct 23, 2020
  17. Elijah NewrenOct 24, 2020
  18. 9/9 t6423: add more details about direct resolution of directoriesElijah Newren via GitGitGadget, Oct 23, 2020
  19. Elijah NewrenOct 23, 2020
  20. 7/9 t6423, t6436: note improved ort handling with dirty filesElijah Newren via GitGitGadget, Oct 23, 2020
  21. 8/9 t6423: note improved ort handling with untracked filesElijah Newren via GitGitGadget, Oct 23, 2020
  22. 0/9 Support both merge backends in the testsuite, via environment variableElijah Newren via GitGitGadget, Oct 26, 2020
  23. 7/9 t6423, t6436: note improved ort handling with dirty filesElijah Newren via GitGitGadget, Oct 26, 2020
  24. 9/9 t6423: add more details about direct resolution of directoriesElijah Newren via GitGitGadget, Oct 26, 2020
  25. 8/9 t6423: note improved ort handling with untracked filesElijah Newren via GitGitGadget, Oct 26, 2020
  26. 6/9 merge tests: expect slight differences in output for recursive vs. ortElijah Newren via GitGitGadget, Oct 26, 2020
  27. 5/9 t6423: expect improved conflict markers labels in the ort backendElijah Newren via GitGitGadget, Oct 26, 2020
  28. 4/9 t6404, t6423: expect improved rename/delete handling in ort backendElijah Newren via GitGitGadget, Oct 26, 2020
  29. 2/9 merge tests: expect improved directory/file conflict handling in ortElijah Newren via GitGitGadget, Oct 26, 2020
  30. 1/9 t/: new helper for tests that pass with ort but fail with recursiveElijah Newren via GitGitGadget, Oct 26, 2020
  31. 3/9 t6416: correct expectation for rename/rename(1to2) + directory/fileElijah Newren via GitGitGadget, Oct 26, 2020

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.