Duy Nguyen <pclo...@gmail.com> writes: >> That is, wouldn't you rather see "worktree lock to/foo" work when >> 'foo' is ambiguous but 'to/foo' is not? > > I don't know. I suppose if people have to make `basename $path` the > same because of some weird build settings, e.g. abc/git and def/git, > then this basename selection becomes useless. > > I had similar thought though, if you only have a worktree named "foo" > then "fo" or even "f" should be unambiguous and can also identify a > worktree, similar to short sha-1. But I discarded that idea because of > the higher chances that typos can select a wrong worktree.
I do not think abbreviation of "foo" down to "fo" is sensible at all. I would instead suggest "path-component-wise tail match", i.e. "to/foo" would match "path/to/foo", "path/TO/FOO" (on fold-case filesystems), but not "pathto/foo". > We would > need to convert or match both '/' and '\' in "to/foo" case because of > Windows, so it's not much easier than basename(). I never said "easier to implement". But can this codepath get backslashed paths in the first place? I somehow thought that normalization would happen a lot before the control reaches here. You'll be calling into fspathcmp() anyway; shouldn't the function know that '/' and '\' are equivalent on some platforms, or is it legal to only call fspathcmp() on a single path component without directory separator? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
