On Wed, Jun 1, 2016 at 12:51 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > >> This allows the user to do something like "worktree lock foo" instead of >> "worktree lock <path/to/foo>". With completion support it could be quite >> convenient. While this base name search can be done in the same worktree >> iteration loop, the code is split into a separate function for clarity. > > Makes me wonder if you want to do this without calling basename(3) > function at all. I do not think such a feature would cost that much > over what we see in this patch. > > 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. We would need to convert or match both '/' and '\' in "to/foo" case because of Windows, so it's not much easier than basename(). -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html