See also #214, #336

/cc @phkelley

Some random findings:

• git branch, git tag, git remote all return a list of alphasorted names (à la OrdinalComparison). At least in my msysgit env.
• case insensitivity seem to be well... not evenly distributed

$ git rev-parse HEAD
34807a6b50c39ba799b6c592ccef086bc6b0d06f

$ git rev-parse HEAd
34807a6b50c39ba799b6c592ccef086bc6b0d06f

$ git rev-parse hEAd
34807a6b50c39ba799b6c592ccef086bc6b0d06f

$ git rev-parse MaStEr
MaStEr
fatal: ambiguous argument 'MaStEr': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

$ git rev-parse master
c1743ba7f9547f53d565222f628fbc7138a65973

$ git rev-parse refs/heads/master
c1743ba7f9547f53d565222f628fbc7138a65973

$ git rev-parse ReFs/heads/master
ReFs/heads/master
fatal: ambiguous argument 'ReFs/heads/master': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

or

$ echo t > a.z

$ git add a.Z

$ git status
# On branch PathComparer
# Your branch is ahead of 'dahlbyk/PathComparer' by 1 commit.
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       a.z
nothing added to commit but untracked files present (use "git add" to track)

$ git add a.z
warning: LF will be replaced by CRLF in a.z.
The file will have its original line endings in your working directory.

$ git status
# On branch PathComparer
# Your branch is ahead of 'dahlbyk/PathComparer' by 1 commit.
#
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   a.z
#

$

I haven't got any issue diverging from git implementation, but we'll have to be backed up by a thick test suite to express, platform by platform, what is the proposed behavior.

Thoughts?

git branch, git tag, git remote all return a list of alphasorted names (à la OrdinalComparison). At least in my msysgit env.

Mine too, I was on the fence about changing this.

I haven't got any issue diverging from git implementation, but we'll have to be backed up by a thick test suite to express, platform by platform, what is the proposed behavior.

That's what I'm afraid of. Realistically, I'm using PathComparer here far more than it probably should be. Ideally most ignorecase type stuff will be handled by libgit2 and we just need to be aware of it in a few places (e.g. #345).

More generally, I'm still on the fence about IPathComarable (or IPathAccessor or whatever)...I think it might be better to just provide the generic comparer that accepts a lambda.

I don't think I understand this PR. What is the goal here? I do agree that there are some places in libgit2sharp where we need to understand the case-sensitive or case-insensitive nature of the underlying filesystem. For example, I think there is a method on Index (Index.Stage?) where we take in an absolute path and have to check to see whether or not that absolute path is underneath the working directory for the repository. I noticed a while back that that string comparer was Ordinal, all the time, which isn't right on Windows. (But it is on some platforms where Libgit2sharp runs under Mono.) So we need some logic for picking a path comparer in that context. But isn't ignorecase support the purview of libgit2? These are just bindings.

What is the goal here?

Case-insensitivity where it's necessary. Identifying where it's necessary is a work in progress. I started by using PathComparer almost everywhere we use StringComparer/StringComparison, but that's clearly not correct.

But isn't ignorecase support the purview of libgit2? These are just bindings.

For the most part, but there are cases where we do things like sort index entries that depend on case-sensitivity. If I do a dir on Windows, it's sorted case-insensitively; for a list of modified files, it may make sense to do the same. Or maybe we just make the call that sorting refs, files, etc. isn't our responsibility and we can throw all of this away.

In the Index.Stage() example, is it reasonable to respect core.ignorecase for that underneath-WD check, or should it depend on an OS check instead?

Thanks Keith for the explanation and your patience with me.

I think you can make the argument either way on that Index.Stage() example as to what the best implementation is. Probably it's more correct to try to detect what platform we're running on and determine case-sensitivity that way -- but it's easier to just look at core.ignorecase. I think either one is acceptable.

I'm not sure that we should start guaranteeing a sort order on collections that we get back from libgit2 -- refs, index entries, etc. There is a perf cost to sorting, and ownership of the sort order probably ought to be a guarantee that either originates all the way down the stack and flows up from there, or is applied at the top of the stack by the eventual consumer. But applying a sort in the middle of the stack (which is what Libgit2sharp is) feels weird to me.

I tend to agree with @phkelley about the sorting on things like refs and the like. Me personally, I would expect enumerating the Index, or a Tree, to match the sorting that's inbuilt to those objects.

For something like git-tf, I can imagine enumerating Tree entries, and then having to sort them back to the weird tree format...

I presume that as a consumer I would have some control over sorting, but I just thought I'd throw that out there.

I'm not sure that we should start guaranteeing a sort order on collections that we get back from libgit2 -- refs, index entries, etc. There is a perf cost to sorting, and ownership of the sort order probably ought to be a guarantee that either originates all the way down the stack and flows up from there, or is applied at the top of the stack by the eventual consumer. But applying a sort in the middle of the stack (which is what Libgit2sharp is) feels weird to me.

I'm the one to blame here. I think I did add the initial .Sort() and .OrderBy() calls when building the Enumerators.

👍 to drop them.

and ownership of the sort order probably ought to be a guarantee that either originates all the way down the stack and flows up from there

One thing to note though regarding loose references: IIRC @carlosmn explained me once that there's no guarantee that git_path_direach() will return anything sorted.

Right, a directory listing will be in whatever order the OS feels like (at least on unix). The index and trees have inherent order (and the trees have odd sorting so these both match) inside them, but there is no particular sorting of refs that makes more sense, particularly since you usually want to filter them by type anyway.

Let's try this again... I've refocused on places where we use case-sensitive comparison for paths within the working directory (Index.Stage(), etc). I didn't touch Conflict until we figure out what's going on with #345.

I also included 07fc2c3ddae3367410763134ec3ff043fe29e2cd to remove sorting - from a consumer standpoint, this is a UX-breaking change.

Updated with fixes for the failing Travis tests around the sorting change.

Down to one failing test:

error : LibGit2Sharp.Tests.IndexFixture.CanStageANewFileWithAFullPath(ignorecase: True): LibGit2Sharp.LibGit2SharpException : An error was raised by libgit2. Category = Os (NotFound).
Failed to stat file '/home/travis/build/libgit2/libgit2sharp/LibGit2Sharp.Tests/bin/Release/TestRepos/30978dcb/NEW_UNTRACKED_FILE.TXT': No such file or directory
error : at LibGit2Sharp.Core.Ensure.HandleError (Int32 result) [0x00000] in <filename unknown>:0
 at LibGit2Sharp.Core.Ensure.ZeroResult (Int32 result) [0x00000] in <filename unknown>:0
 at LibGit2Sharp.Core.Proxy.git_index_add_bypath (LibGit2Sharp.Core.Handles.IndexSafeHandle index, LibGit2Sharp.Core.FilePath path) [0x00000] in <filename unknown>:0
 at LibGit2Sharp.Index.AddToIndex (System.String relativePath) [0x00000] in <filename unknown>:0
 at LibGit2Sharp.Index.Stage (IEnumerable`1 paths) [0x00000] in <filename unknown>:0
 at LibGit2Sharp.Index.Stage (System.String path) [0x00000] in <filename unknown>:0
 at LibGit2Sharp.Tests.IndexFixture.AssertStage (Nullable`1 ignorecase, IRepository repo, System.String path) [0x00000] in <filename unknown>:0
 at LibGit2Sharp.Tests.IndexFixture.CanStageANewFileWithAFullPath (Boolean ignorecase) [0x00000] in <filename unknown>:0 

@carlosmn If ignorecase = true on a case-sensitive platform, is it expected that one would not be able to stage a file using the wrong case?

@carlosmn If ignorecase = true on a case-sensitive platform, is it expected that one would not be able to stage a file using the wrong case?

Looks like this goes down to "Is there a way to make fopen() case insensitive on a Linux based platform?". I don't think so.

I can think of a hack to make this work, though. Beware, it's ugly and greedy:

• Retrieve the content of the parent directory
• Make a case sensitive comparison for each entry
  • One exact match => Stage() it and exit
• Make a case insensitive comparison on each entry
  • One match => Stage() it
  • More than one match => throw an AmbiguousBlaBlaBlaException

Ugly and greedy, isn't it? I told you. 😉 There's an additional bonus drawback, this couldn't support glob patterns that are about to be introduced by #343 (through the diff-based approach).

Ugly and greedy, isn't it?

Yes

Ultimately I think our behavior needs to mimic git.git here. Does it even try to support core.ignorecase = true on *nix?

The core.ignorecase option is a way to tell git that the is underlying filesystem case-insensitive; and that's all it's for. It's not a way of asking it to behave as though it were in a case-insensitive filesystem.

EDIT: it does support it on unix if you mount NTFS for example. It's not about the OS but about the filesystem, you can have either on OSX.

What do you think of 4673aa7 to skip ignorecase = true if the filesystem won't support it?

So per @yorah's comments, it sounds like the only case-sensitivity fix we actually need is what @phkelley noted in #214. I'll drop the RepositoryStatus and TreeChanges bits, which just leaves the relative path fixes. I probably should have just started there, eh?

@dahlbyk Travis doesn't look happy... Could you please peek at those?

StatusFixture.cs(39,13): error CS0815: An implicitly typed local variable declaration cannot be initialized with `void'
StatusFixture.cs(55,24): error CS0411: The type arguments for method `Xunit.Assert.Equal<T>(T, T, System.Collections.Generic.IEqualityComparer<T>)' cannot be inferred from the usage. Try specifying the type arguments explicitly
StatusFixture.cs(71,24): error CS0411: The type arguments for method `Xunit.Assert.Equal<T>(T, T, System.Collections.Generic.IEqualityComparer<T>)' cannot be inferred from the usage. Try specifying the type arguments explicitly
StatusFixture.cs(74,24): error CS0411: The type arguments for method `Xunit.Assert.Equal<T>(T, T, System.Collections.Generic.IEqualityComparer<T>)' cannot be inferred from the usage. Try specifying the type arguments explicitly

Should be fixed now...missed a test that I thought I'd rolled back.

Update on top of latest, but...what seems to be an unrelated test is failing. Naturally it works on my machine... Ideas?

LibGit2Sharp.Tests.CommitFixture.CanEnumerateAllCommits: Assert.Equal() Failure
Position: First difference is at position 7
Expected: String[] { "44d5d18", "bb65291", "532740a", "503a16f", "3dfd6fd", "4409de1", "902c60b", "4c062a6", "e90810b", "6dcf9bf", "a4a7dce", "be3563a", "c47800c", "9fd738e", "4a202b3", "41bc8c6", "5001298", "5b5b025", "8496071" }
Actual: String[] { "44d5d18", "bb65291", "532740a", "503a16f", "3dfd6fd", "4409de1", "902c60b", "e90810b", "6dcf9bf", "4a202b3", "41bc8c6", "5001298", "5b5b025", "8496071" }
at LibGit2Sharp.Tests.CommitFixture.AssertEnumerationOfCommitsInRepo (LibGit2Sharp.Repository repo, System.Func`2 filterBuilder, IEnumerable`1 abbrevIds) [0x00000] in <filename unknown>:0
at LibGit2Sharp.Tests.CommitFixture.AssertEnumerationOfCommits (System.Func`2 filterBuilder, IEnumerable`1 abbrevIds) [0x00000] in <filename unknown>:0
at LibGit2Sharp.Tests.CommitFixture.CanEnumerateAllCommits () [0x00000] in <filename unknown>:0 

Update on top of latest, but...what seems to be an unrelated test is failing. Naturally it works on my machine... Ideas?

It looks like the failure comes from 8e8ba01. I've cherry picked it onto the top of vNext and ran it on TeamCity. The Mono build configuration failed as well.

Good call...overlooked the use of unsorted Refs. 💚

❤️ Thanks a lot for this very cool piece of work.

Merged!