Re: [PATCH v3 4/6] worktree.c: retrieve lock status (and optionally reason) in get_worktrees()

2016-06-01 Thread Junio C Hamano
Duy Nguyen writes: > On Wed, Jun 1, 2016 at 12:55 AM, Junio C Hamano wrote: >> Nguyễn Thái Ngọc Duy writes: >> >>> We need this later to avoid double locking a worktree, or unlocking one >>> when it's not even locked. >> >> Shouldn't

Re: [PATCH v3 4/6] worktree.c: retrieve lock status (and optionally reason) in get_worktrees()

2016-06-01 Thread Duy Nguyen
On Wed, Jun 1, 2016 at 12:55 AM, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy 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

Re: [PATCH v3 4/6] worktree.c: retrieve lock status (and optionally reason) in get_worktrees()

2016-05-31 Thread Junio C Hamano
Nguyễn Thái Ngọc Duy 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

[PATCH v3 4/6] worktree.c: retrieve lock status (and optionally reason) in get_worktrees()

2016-05-30 Thread Nguyễn Thái Ngọc Duy
We need this later to avoid double locking a worktree, or unlocking one when it's not even locked. Signed-off-by: Nguyễn Thái Ngọc Duy --- worktree.c | 12 worktree.h | 1 + 2 files changed, 13 insertions(+) diff --git a/worktree.c b/worktree.c index