Add unmatched pathspecs options #343

yorah · 2013-02-19T16:16:06Z

This is related to #274

💤 Implementation in progress
🔦 Ready for review
🎱 more work
⭐ Really ready for review this time

Points of attention:

Remove() is not included in this PR.
This PR includes some bug fixing related to Remove unnecessary finalizers #330 (the bugs were there before, they were just put into light by the aforementionned PR)

yorah · 2013-02-19T16:16:51Z

/cc @jamill

yorah · 2013-02-19T16:54:28Z

As a bonus, the build is now 💚

For Stage(), I had to include Unmodified records, to differentiate between:

a non-existent file
a removed file
an unaltered file (which acts as an unmatched pathspec when we don't include Unmodified files)
a file that was already added to the index (same thing)

I have the feeling I'm missing some other edge cases though, but can't figure out which ones...

dahlbyk · 2013-02-19T17:02:36Z

LibGit2Sharp/Core/Proxy.cs

@@ -253,7 +253,7 @@ public static Signature git_commit_committer(GitObjectSafeHandle obj)
        {
            using (ThreadAffinity())
            using (var treePtr = new ObjectSafeWrapper(tree.Id, repo))
-            using (var parentObjectPtrs = new DisposableEnumerable<ObjectSafeWrapper>(parentIds.Select(id => new ObjectSafeWrapper(id, repo))))
+            using (var parentObjectPtrs = new DisposableEnumerable<ObjectSafeWrapper>(parentIds.Select(id => new ObjectSafeWrapper(id, repo)).ToArray()))


Using ToList() here would avoid an extra array allocation for the final result.

Based on usage of parentObjectPtrs.Count() below, should DisposableEnumerable be converted to DisposableCollection to avoid an extra enumeration?

yorah · 2013-02-21T10:37:26Z

Latest changes:

implemented @dahlbyk proposal regarding DisposableEnumerable (actually, I just exposed a Count property to avoid the extra enumeration => I did not feel like implementing the whole ICollection<T> interface as we don't need it).
by default, pathspec validation is now strict. This means that unless you specify otherwise, an exception will be thrown if one of the passed path/pathspec doesn't match.

dahlbyk · 2013-02-21T15:59:13Z

actually, I just exposed a Count property to avoid the extra enumeration => I did not feel like implementing the whole ICollection interface as we don't need it

👍

nulltoken · 2013-02-21T19:33:03Z

@yorah I cherry picked the first five commits and pushed them into vNext. Could you please rebase this PR to drop them?

by default, pathspec validation is now strict. This means that unless you specify otherwise, an exception will be thrown if one of the passed path/pathspec doesn't match.

I'm in favor of this approach. And the code looks pretty clean.

However, as this is quite a breaking change, I'd like to wait for some days to see if the other contributors have anything to say about this.

yorah · 2013-02-22T15:46:21Z

Rebased and running.

As a bonus, I will also add some test coverage related to accepting globs as pathspecs for staging/unstaging. In the next few days.

yorah · 2013-02-26T17:28:29Z

Added some tests related to accepting globs as pathspecs. Passing "*" is currently broken, waiting for feedback on libgit2/libgit2#1367.

Does anyone have an opinion related to the change of behaviour (strict vs lax)? Please? 🐱

yorah · 2013-03-11T15:12:53Z

Proposal as of now (current code)

Only throw/notify for explicit paths (renamed the PathspecsOptions class to ExplicitPathsOptions to match what it does).

Advantages I see:

simple and predictable behavior
no breaking changes with what was previously there (if you don't pass an ExplicitPathsOptions instance, no notify/throw is done, and you get standard pathspec matching)

@dahlbyk regarding the proposal you made in libgit2/libgit2#1367, I think checking if offending pathspecs match any of the already found files in libgit2sharp is not easily feasible. This would mean either exposing the _fnmatch functionality implemented in libgit2 (which doesn't feel right), or re-implementing our own fnmatch. We would also have to take the ignore_case flag into account.

RFC

Before going further, I would like to make a request for comments.

Basically, the initial question this PR tries to address boils down to:
Is it ok to stage/unstage (and remove/move) a file which doesn't exist?

I think there are two main cases:

the client passes a list of pathspecs
the client passes a list of explicit paths
~~the client passes a mix of both~~ (unlikely corner case, excluded on purpose => this looks like a "slippery slope"™, as the result will depend on the way the list is being sorted)

So the question can also be reformulated as:
What should be the expected behavior when a path/pathspec is unmatched?
Silently ignore? Notify? Throw?

@haacked @dahlbyk @jamill @ethomson

dahlbyk · 2013-03-14T02:47:52Z

@nulltoken would it be possible to cherry-pick 144ac99 and 5675ea0 so it's easier to read the core PR?

What should be the expected behavior when a path/pathspec is unmatched?

I'll defer to people that are actually building clients that need to Stage/Unstage.

nulltoken · 2013-03-14T19:38:28Z

@nulltoken would it be possible to cherry-pick 144ac99 and 5675ea0 so it's easier to read the core PR?

@dahlbyk Done!

nulltoken · 2013-03-14T19:39:32Z

@yorah Could you please rebase this PR on top of vNext?

yorah · 2013-03-18T10:46:11Z

Could you please rebase this PR on top of vNext?

Done!

@haacked @jamill whenever you have time, I would really appreciate your feedback.

nulltoken · 2013-04-07T09:22:36Z

LibGit2Sharp.Tests/StageFixture.cs

+         */
+        [Theory]
+        [InlineData("*u*", 0)]
+        //[InlineData("*", 0)] TODO: waiting for https://github.com/libgit2/libgit2/pull/1367


What's the current status of this?

Working with my latest proposal, uncommenting.

All the overloads can now report and/or fail upon unmatched explicit paths. By default, the passed list of paths will be treated as a list of pathspecs. When an ExplicitPathsOptions is passed to the overloads, this list of paths will be treated as explicit paths. In that case, the default behavior is to throw when one of this explicit path is unmatched.

nulltoken · 2013-04-09T19:19:36Z

👍 Merged

yorah · 2013-04-09T19:24:48Z

Cool!

@dahlbyk I think this impacts your submodule PR (for the Stage() method, where we now rely on diff). Unless you beat me to it, I will have a look tomorrow to see if there is an easy way to make it work nicely with your PR!

dahlbyk reviewed Feb 19, 2013
View reviewed changes

nulltoken mentioned this pull request Feb 22, 2013

Ignore Case via Repository.PathComparer #344

Closed

3 tasks

yorah mentioned this pull request Feb 26, 2013

Correctly return matched pathspec when passing "*" or "." libgit2/libgit2#1367

Merged

yorah mentioned this pull request Mar 14, 2013

Diff.Compare overload to include untracked changes #359

Closed

nulltoken reviewed Apr 7, 2013
View reviewed changes

yorah added 3 commits April 9, 2013 16:07

Add ExplicitPathsOptions to Repository.Reset()

6419588

Add ExplicitPathsOptions to Repository.Index.Unstage()/Stage()

9405ac1

nulltoken closed this Apr 9, 2013

yorah deleted the topic/unmatched-pathspecs branch April 9, 2013 19:25

dahlbyk mentioned this pull request Apr 10, 2013

Submodules! #312

Merged

13 tasks

Add unmatched pathspecs options #343

Add unmatched pathspecs options #343

Uh oh!

Conversation

yorah commented Feb 19, 2013

Uh oh!

yorah commented Feb 19, 2013

Uh oh!

yorah commented Feb 19, 2013

Uh oh!

dahlbyk Feb 19, 2013

Choose a reason for hiding this comment

Uh oh!

yorah commented Feb 21, 2013

Uh oh!

dahlbyk commented Feb 21, 2013

Uh oh!

nulltoken commented Feb 21, 2013

Uh oh!

yorah commented Feb 22, 2013

Uh oh!

yorah commented Feb 26, 2013

Uh oh!

yorah commented Mar 11, 2013

Uh oh!

dahlbyk commented Mar 14, 2013

Uh oh!

nulltoken commented Mar 14, 2013

Uh oh!

nulltoken commented Mar 14, 2013

Uh oh!

yorah commented Mar 18, 2013

Uh oh!

nulltoken Apr 7, 2013

Choose a reason for hiding this comment

Uh oh!

yorah Apr 9, 2013

Choose a reason for hiding this comment

Uh oh!

nulltoken commented Apr 9, 2013

Uh oh!

yorah commented Apr 9, 2013

Uh oh!

Uh oh!