On Thu, Feb 21, 2019 at 8:50 PM Michal Suchánek <msucha...@suse.de> wrote:
>
> On Thu, 21 Feb 2019 17:50:38 +0700
> Duy Nguyen <pclo...@gmail.com> wrote:
>
> > On Tue, Feb 19, 2019 at 12:05 AM Michal Suchanek <msucha...@suse.de> wrote:
> > >
> > > When adding wotktrees git can die in get_common_dir_noenv while
> > > examining existing worktrees because the commondir file does not exist.
> > > Rather than testing if the file exists before reading it handle ENOENT.
> >
> > I don't think we could go around fixing every access to incomplete
> > worktrees like this. If this is because of racy 'worktree add', then
> > perhaps a better solution is make it absolutely clear it's not ready
> > for anybody to access.
> >
> > For example, we can suffix the worktree directory name with ".lock"
> > and make sure get_worktrees() ignores entries ending with ".lock".
> > That should protect other commands while 'worktree add' is still
> > running. Only when the worktree is complete that 'worktree add' should
> > rename the directory to lose ".lock" and run external commands like
> > git-checkout to populate the worktree.
>
> The problem is we don't forbid worktree names ending with ".lock".
> Which means that if we start to forbid them now existing worktrees
> might become inaccessible.

Worktrees ending with .lock will not work well now anyway. While [1]
reports the problem with worktree names having a whitespace, ".lock"
is in the same class (not a valid refname) and will result the same
error. So if you have "*.lock" worktrees now you're already in
trouble.

[1] 
https://public-inbox.org/git/1550673274.3073...@yandex.ru/T/#m9d86e0a388fd4961bc102c2c69e8bc3b2db07a42
-- 
Duy

Reply via email to