Re: git merge-tree: bug report and some feature requests

From: Edward Thomson <ethomson@edwardthomson.com>
Date: Jan 23, 2018, 11:52 UTC
Message-ID: <CA+WKDT3ZsObXc2ENV3gUXbMZU=McBJdiEpvk7y2OM0t+PrqZtQ@mail.gmail.com>
In-Reply-To: <CAFAcib9FGfTe8C7TaOY91kzhUvxXtpx5Y8JMFkqxhRhLJeytxg@mail.gmail.com>

On Tue, Jan 23, 2018 at 7:08 AM, Josh Bleecher Snyder <josharian@gmail.com> wrote:

> Looking over your list above, at a minimum, libgit2 might not have a
> particularly good way to represent submodule/file or
> submodule/directory conflicts, because is-a-submodule is defined
> external to a git_index_entry.

libgit2 should detect submodule/file and submodule/directory conflicts.

While, yes, some metadata about the submodule is located outside the index, you can look at the mode to determine that this _is_ a submodule. You should be able to reliably detect submodule/file conflicts because one will be a regular or executable file (mode 0100644 or 0100755), while the other entry at the same path will be a gitlink (mode 0160000).

Similarly, submodule/directory conflict detection works just like regular file/directory conflict detection. If some path `foo` is a submodule (or a regular file) then some path `foo/bar` existing in the other side of the merge causes a conflict.

Show 5 quoted lines

> Cataloging or special-casing all possible conflict types does seem
> unwise because of the sheer number of kinds of conflicts.
>
> But the alternative appears to be punting entirely, as libgit2 does,
> and merely providing something akin to three index entries.

Indeed, when I added merge to libgit2, we put the higher-level conflict analysis into application code because there was not much interest in it at the time. I've been meaning to add this to `git_status` in libgit2, but it's not been a high priority.

Show 6 quoted lines

> This which
> leaves it unclear what exactly the conflict was, at which point any
> user (read: porcelain developer) will end up having to recreate some
> merge logic to figure out what went wrong. And if merge-tree starts
> doing rename detection, the user might then have to emulate that as
> well.

That's not a good idea. Trying to figure out what merge did would be painful at best, and likely impossible, since a rename conflict is recorded in the main index without any way to piece it together. eg:

100644 deadbeefdeadbeefdeadbeefdeadbeefdeadbeef 1 bar.c 100644 cafec4fecafec4fecafec4fecafec4fecafec4fe 2 bar.c 100644 c4cc188a892898e13927dc4a02e7f68814b874b2 1 foo.c 100644 71f5af150b25e3aaaad2d67ff46759311401036f 2 foo.c 100644 351cfbdd55d656edd2c5c995aae3caafb9ec11fa 3 rename1.c 100644 e407c7d138fb457674c3b114fcf47748169ab0c5 3 rename2.c

This is the main index that results when bar.c has a rename/edit conflict, and foo.c also has a rename/edit conflict. One was renamed to rename1.c and the other to rename2.c. Trying to determine which is which _after the fact_ would be regrettable. Especially since rename detection is not static - you would need to know the thresholds that were configured at the time merge was performed and try to replay the rename detection with that.

libgit2 records a `NAME` section in the index that pairs the rename detection decisions that it performed so that you can analyze them and display them after the fact.

-ed