On Wed, Jun 1, 2016 at 12:55 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > >> We need this later to avoid double locking a worktree, or unlocking one >> when it's not even locked. > > Shouldn't this be done lazily? > > If a user is working in worktree B and is not doing anything funky, > she would not care why worktree A and C are locked, even though she > might care the fact that they are locked. You and Eric will have to settle this. It was done lazily in v2, but Eric convinced me this lock thing will be needed for many worktree commands (list, lock, unlock, move, remove and maybe even prune) that it makes more sense to make it a field in struct worktree instead. For a dozen worktrees, it does not really matter. But get_worktrees() is also being used outside "git worktree" command, some of those new callers may get picky. Maybe a common ground is adding a flag to get_worktrees() to select what fields to be filled? -- 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