Nickolai Belakovski writes:
> Either way, I do see an issue with the current code that anybody who
> wants to know the lock status and/or lock reason of a worktree gets
> faced with a confusing, misleading, and opaque piece of code.
Sorry, I don't. I do not mind a better documentation for
On Mon, Oct 29, 2018 at 1:45 AM Nickolai Belakovski
wrote:
> On Sun, Oct 28, 2018 at 9:01 PM Eric Sunshine wrote:
> > That said, I wouldn't necessarily oppose renaming the function, but I
> > also don't think it's particularly important to do so.
>
> To me, I would just go lookup the signature
On Sun, Oct 28, 2018 at 9:01 PM Eric Sunshine wrote:
>
> On Sun, Oct 28, 2018 at 9:11 PM Nickolai Belakovski
> wrote:
> > I would also suggest renaming is_worktree_locked to
> > worktree_lock_reason, the former makes me think the function is
> > returning a boolean, whereas the latter more
On Sun, Oct 28, 2018 at 8:52 PM Junio C Hamano wrote:
>
>
> If the field "reason" should always be populated, there is *no*
> reason why we need the "valid" boolean. They work as a pair to
> realize lazy population of rarely used field. The lazy evaluation
> technique is used as an optimization
On Sun, Oct 28, 2018 at 9:11 PM Nickolai Belakovski
wrote:
> On Sun, Oct 28, 2018 at 4:03 PM Eric Sunshine wrote:
> > Aside from that, it doesn't seem like worktree needs any changes for
> > the ref-filter atom you have in mind. (Don't interpret this
> > observation as me being averse to changes
Nickolai Belakovski writes:
> This is an improvement because it fixes an issue in which the fields
> lock_reason and lock_reason_valid of the worktree struct were not
> being populated.
If the field "reason" should always be populated, there is *no*
reason why we need the "valid" boolean. They
On Sun, Oct 28, 2018 at 4:03 PM Eric Sunshine wrote:
>
> On Sun, Oct 28, 2018 at 5:55 PM Nickolai Belakovski
> > wrote: This was meant to be a reply to
> >
On Sun, Oct 28, 2018 at 5:55 PM Nickolai Belakovski
> wrote: This was meant to be a reply to
> https://public-inbox.org/git/cac05386f1x7tspr6kgkulwewsmdiq4vktf5rxahvzpkwbmx...@mail.gmail.com/T/#m8898c8f7c68e1ea234aca21cb2d7776b375c6f51,
> please look there for some more context. I think it both
This was meant to be a reply to
https://public-inbox.org/git/cac05386f1x7tspr6kgkulwewsmdiq4vktf5rxahvzpkwbmx...@mail.gmail.com/T/#m8898c8f7c68e1ea234aca21cb2d7776b375c6f51,
please look there for some more context. I think it both did and
didn't get listed as a reply? In my mailbox I see two
nbelakov...@gmail.com writes:
> From: Nickolai Belakovski
>
> lock_reason_valid is renamed to is_locked and lock_reason is removed as
> a field of the worktree struct. Lock reason can be obtained instead by a
> standalone function.
>
> This is done in order to make the worktree struct more
From: Nickolai Belakovski
lock_reason_valid is renamed to is_locked and lock_reason is removed as
a field of the worktree struct. Lock reason can be obtained instead by a
standalone function.
This is done in order to make the worktree struct more intuitive when it
is used elsewhere in the
11 matches
Mail list logo
