On Thu, Feb 21, 2019 at 8:50 PM Michal Suchánek <msuchanek@xxxxxxx> wrote: > > On Thu, 21 Feb 2019 17:50:38 +0700 > Duy Nguyen <pclouds@xxxxxxxxx> wrote: > > > On Tue, Feb 19, 2019 at 12:05 AM Michal Suchanek <msuchanek@xxxxxxx> 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.30738.0@xxxxxxxxx/T/#m9d86e0a388fd4961bc102c2c69e8bc3b2db07a42 -- Duy
