Expose conflicted entries in Index #279

Closed
nulltoken opened this Issue Dec 22, 2012 · 5 comments

Comments

Projects
None yet
3 participants
Member

nulltoken commented Dec 22, 2012

Current status:

  • Currently the Index contains fully merged staged entries (where stage = 0) and conflicted entries (where stage > 0).
  • The Count property returns the total number of entries (ie. staged + conflicted).
  • When enumerating the Index, conflicted entries are returned.
  • However, there's no way to retrieve the conflicted entries per path.

I was thinking of changing the return type of the indexer as follows

  • Current: public virtual IndexEntry this[string path]
  • Proposed: public virtual IEnumerable<IndexEntry> this[string path]

Depending on the content of the Index regarding the passed path, the output would obviously vary:

  • Fully merged: returns a sequence of one IndexEntry
  • Conflicted: returns a sequence of three IndexEntrys (Ancestor, Ours, Theirs)
  • NonExistent : returns a sequence of zero IndexEntry

Feedback? Thoughts?

Member

dahlbyk commented Dec 22, 2012

We could come up with some example usage scenarios, but my instinct is that consuming that result as a sequence wouldn't make for particularly clean code...

Which IndexEntry does this[string path] return now for conflicts? Supposing it returns the Theirs entry, for example, we could add IndexEntry Ancestor and IndexEntry Ours properties to expose the other states, returning null if the entry is not conflicted.

Owner

carlosmn commented Sep 1, 2013

To me it feels like the this[string] access should be about the simplest possible, so it should return the zeroth stage entry as IMO that would be the most common thing you want to do . If the user does want to deal with stages, then there should be an explicit way of doing so, like index.Conflicts[string] or index.Entries(string) or whatever.

Member

dahlbyk commented Sep 1, 2013

... like index.Conflicts[string]...

This is exactly what is supported now: https://github.com/libgit2/libgit2sharp/blob/vNext/LibGit2Sharp.Tests/ConflictFixture.cs#L74-91

This issue can probably be closed.

Member

nulltoken commented Sep 1, 2013

@dahlbyk you're right.

nulltoken closed this Sep 1, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment