Better way to identify conflict in a status

[yishaigalatzer]

When Calling Index.RetrieveStatus(path) and the underlying file is in a conflict state the returned value is currently multiple flags.

This behavior is changing from version to version and a bit hard to code reliably against.

It would be beneficial to consider a FileStatus.Conflict and return it in this case.

[nulltoken]

@yishaigalatzer What version of LibGit2Sharp are you running against (a call to Repository.Version should answer that)? Would you please be so kind as to provide us with some simple repro steps as well?

@ethomson I'm pretty sure libgit2/libgit2#1111 has been included in the latest binary upgrade.

[ethomson]

Indeed it is. @yishaigalatzer you shouldn't be seeing conflicts in the status. Are you saying you want to see conflicts?

[yishaigalatzer]

Version = 0.9.5-unknown-16e6cee (x86)

What I'm saying is I did a pull from command line, that indeed ends up in a conflict state. So far it's fine.

I'm looking to get a proper conflict state from libgit2sharp

[nulltoken]

I'm looking to get a proper conflict state from libgit2sharp

I thought that we were discussing about a bug in the way Index.RetrieveStatus(path) was working ( "the returned value is currently multiple flags" ). And now, I'm unsure of what you're after ( "I'm looking to get a proper conflict state from libgit2sharp" ).

Let's try another approach. Hopefully, it will get through my thick skull.

• What are the repro steps to put the repository in the initial state?
• What's the code you're running that returns an unexpected value?
• What other value do you think should be returned?

[arrbee]

I suspect you all already know this, but to make it explicit: libgit2 currently ignores files in a conflict state in both diff and status. Unfortunately, I don't think I'll have time to tackle that situation until after the libgit2 1.0 release (i.e. in the next month) but at some point, I do think we should expand status to indicate that a file has conflicts and expand diff to show the 3-way diff that core git does when diffing a file with conflicts.

I'd love to have a discussion about how this should be exposed so we'll have a good API ready to go when we're ready to start on implementation.

[nulltoken]

@yishaigalatzer See (loosely) related #279

[yishaigalatzer]

@arrbee I agree with your view of things. I do have a good working solution until that happens.

Feel free to close, or keep around to track @arrbee's suggestion

[dahlbyk]

To provide a specific example, in the conflict test repo provided by #334 our status looks like this:
+0 ~2 -5 | +7 ~0 -0 | i0

In git.git:

PS [master +2 ~2 -2 !4 | +2 ~0 -2 !4 !]> git status -sb
## master
UD ancestor-and-ours.txt
DU ancestor-and-theirs.txt
DD ancestor-only.txt
UU conflicts-one.txt
UU conflicts-two.txt
M  one.txt
AA ours-and-theirs.txt
AU ours-only.txt
UA theirs-only.txt
M  two.txt

From an API standpoint, I would think we need new status codes to stand in for a U above, e.g.:

    GIT_STATUS_INDEX_CONFLICT = (1u << 5),
    ...
    GIT_STATUS_WT_CONFLICT = (1u << 11),

[ethomson]

@dahlbyk I'm not sure that I'm following what you mean when you say to stand in for the U...? Also, what's a WT_CONFLICT - a working tree conflict? I don't see status raising one of these, but I haven't thought much about the checkout case - does it return a GIT_STATUS?

[ethomson]

Wait, I think I'm being dense, you're talking about the U as an Unmerged status entry, I think.

If you want a report like the one above, I think you'll need an enum that can cover all the conflict cases (sans rename conflicts -- although that's an interesting discussion for another day): https://github.com/ethomson/libgit2/blob/merge/include/git2/diff_tree.h#L54

[ethomson]

But to be honest, I'm not sure I entirely understand the output of git status -sb, so there's that, also.

[dahlbyk]

Yeah, you're right... I didn't really think this all the way through. git status docs give a nice summary of the possible combinations:

A  A  unmerged, both added       # CONFLICT_BOTH_NEW
A  U  unmerged, added by us      # CONFLICT_OURS_NEW
U  A  unmerged, added by them    # CONFLICT_THEIRS_NEW
D  D  unmerged, both deleted     # CONFLICT_BOTH_DELETED
D  U  unmerged, deleted by us    # CONFLICT_OURS_DELETED
U  D  unmerged, deleted by them  # CONFLICT_THEIRS_DELETED
U  U  unmerged, both modified    # CONFLICT_BOTH_MODIFIED

Or perhaps it would be better to represent conflict status in OURS/THEIRS pairs?

A  A  unmerged, both added       # CONFLICT_OURS_NEW      | CONFLICT_THEIRS_NEW
A  U  unmerged, added by us      # CONFLICT_OURS_NEW      | CONFLICT_THEIRS_MODIFIED
U  A  unmerged, added by them    # CONFLICT_OURS_MODIFIED | CONFLICT_THEIRS_NEW
D  D  unmerged, both deleted     # CONFLICT_OURS_DELETED  | CONFLICT_THEIRS_DELETED
D  U  unmerged, deleted by us    # CONFLICT_OURS_DELETED  | CONFLICT_THEIRS_MODIFIED
U  D  unmerged, deleted by them  # CONFLICT_OURS_MODIFIED | CONFLICT_THEIRS_DELETED
U  U  unmerged, both modified    # CONFLICT_OURS_MODIFIED | CONFLICT_THEIRS_MODIFIED

[dahlbyk]

Or in the context of the test repo:

Current status:

ancestor-and-ours.txt    Removed, Untracked
ancestor-and-theirs.txt  Untracked
ancestor-only.txt        Nonexistent
conflicts-one.txt        Removed, Untracked
conflicts-two.txt        Removed, Untracked
ours-and-theirs.txt      Removed, Untracked
ours-only.txt            Removed, Untracked
theirs-only.txt          Untracked

Instead, maybe something like this?

ancestor-and-ours.txt    ConflictOursModified, ConflictTheirsDeleted
ancestor-and-theirs.txt  ConflictOursDeleted, ConflictTheirsModified
ancestor-only.txt        ConflictOursDeleted, ConflictTheirsDeleted
conflicts-one.txt        ConflictOursModified, ConflictTheirsModified
conflicts-two.txt        ConflictOursModified, ConflictTheirsModified
ours-and-theirs.txt      ConflictOursUntracked, ConflictTheirsUntracked
ours-only.txt            ConflictOursUntracked, ?
theirs-only.txt          ?, ConflictTheirsUntracked

I'm not really sure how you get to the ours-only or theirs-only state...

[yishaigalatzer]

How about that also FileStatus will be including a new flag Unmerged without all the details. You can then access a conflict or unmerged collection and get the details above in one of @dahlbyk suggestions