From: Duy Nguyen <pclouds@gmail.com>
Date: Wed, 01 Jun 2016 13:22:14 GMT
Subject: Re: [PATCH v3 2/6] worktree.c: find_worktree() learns to identify worktrees by basename
Message-ID: <CACsJy8CmdTapWsst-PuwFNH8Uy3Vgow+fKWzQ+tGYPSc=aZsXg@mail.gmail.com>
In-Reply-To: <xmqqh9de5d6e.fsf@gitster.mtv.corp.google.com>

On Wed, Jun 1, 2016 at 12:51 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> 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