Wildcards don't seem to work correctly

[leifg]

In gitsh (version 0.5, without any special git binary) I get the following error:

diff Gemfile*

results in

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

However git diff Gemfile* on the shell works correctly

Any ideas?

[mike-burns]

Marked as enhancement: gitsh does not currently support file globs, but it would be a nice feature.

[georgebrock]

Some Git commands have built in support for globbing patterns (e.g. git-add) others don't (e.g. git-log and git-diff) which is a little annoying. We should definitely smooth out this inconsistency for gitsh users.

[georgebrock]

Idea: if we're going to add globbing support to gitsh, maybe we should have branch and tag globbing too?

show-branch */master

(This might not be that useful, a couple of the use cases I thought of are already natively supported, including tag -l v* and branch --list gb-*)

[mike-burns]

More globs in more places is good. Should we focus on * and ? for now? Would it be straight-forward to attack e.g. ** or *(/) or fancier things as part of this?

[georgebrock]

If we focus on paths, we can lean on Ruby's Dir.glob method, and get *, **, ?, […], and {…} for free!

Figuring out what's meant to be a path and what's not could be tricky, though, although I suppose a general purpose shell would expand anything that matched a path, so it may not matter.

[georgebrock]

That said, it would be really nice to have {…,…} work everywhere, and it wouldn't require any special knowledge of argument types.

[georgebrock]

Another benefit to this: implementing our own globbing would mean we could stop passing shell commands through /bin/sh -c, which in turn would unblock pipelines (#299)

[georgebrock]

With the new tab completion system we can now generate a context-aware list of possible arguments, which we could use as the basis of custom globbing.

It could work something like this:

1. User enters a command with a glob pattern in one or more arguments, e.g. show-branch */master my-feature-branch
2. We see there's a glob in an argument, and ask the tab completion system for possible completions at that point in the command, e.g. pass "show-branch " to the tab completion system, and get back options like ["origin/master", "upstream/master", "--all", "v0.1", …]
3. We filter the options based on the pattern, e.g. we reduce the options to ["origin/master", "upstream/master"]
4. We expand the argument to the available options, e.g. our example command becomes show-branch origin/master upstream/master my-feature-branch

[sharplet]

Here’s another example where the lack of wildcard expansion has unexpected results:

$ git rm -r --cached */xcuserdata
rm 'CallForSupport.xcodeproj/xcuserdata/adsharp.xcuserdatad/xcschemes/xcschememanagement.plist’

# vs.

$ git rm -r --cached "*/xcuserdata"
fatal: pathspec '*/xcuserdata' did not match any files

In gitsh, because wildcards aren’t expanded, running rm -r --cached */xcuserdata is equivalent to the second invocation, where quoting prevents the shell from expanding the wildcard.