Re: [PATCH] worktree: populate lock_reason in get_worktrees and light refactor/cleanup in worktree files

2018-10-25 Thread Eric Sunshine
On Thu, Oct 25, 2018 at 1:47 AM Nickolai Belakovski wrote: > The motivation for the change is some work that I'm doing to add a > worktree atom in ref-filter.c. I wanted that atom to be able to access > all fields of the worktree struct and noticed that lock_reason wasn't > getting populated so I

Re: [PATCH] worktree: populate lock_reason in get_worktrees and light refactor/cleanup in worktree files

2018-10-24 Thread Nickolai Belakovski
The motivation for the change is some work that I'm doing to add a worktree atom in ref-filter.c. I wanted that atom to be able to access all fields of the worktree struct and noticed that lock_reason wasn't getting populated so I figured I'd go and fix that. I figured that since get_worktrees is

Re: [PATCH] worktree: populate lock_reason in get_worktrees and light refactor/cleanup in worktree files

2018-10-24 Thread Eric Sunshine
On Wed, Oct 24, 2018 at 2:39 AM wrote: > lock_reason is now populated during the execution of get_worktrees > > is_worktree_locked has been simplified, renamed, and changed to internal > linkage. It is simplified to only return the lock reason (or NULL in case > there is no lock reason) and to

[PATCH] worktree: populate lock_reason in get_worktrees and light refactor/cleanup in worktree files

2018-10-24 Thread nbelakovski
From: Nickolai Belakovski lock_reason is now populated during the execution of get_worktrees is_worktree_locked has been simplified, renamed, and changed to internal linkage. It is simplified to only return the lock reason (or NULL in case there is no lock reason) and to not have any side