Re: [PATCH v2 1/2] ref-filter: add worktree atom

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 13, 2018, 01:38 UTC
Message-ID: <xmqqd0r9zri6.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20181112122245.GB3956@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 18 quoted lines

>> I wonder if "The worktree at /local/src/wt1 has this branch checked
>> out" is something the user of %(worktree) atom, or a variant thereof
>> e.g. "%(worktree:detailed)", may want to learn, but because that
>> information is lost when this function returns, such an enhancement
>> cannot be done without fixing this funciton.
>
> Hmm. I think for the purposes of this series we could jump straight to
> converting %(worktree) to mean "the path of the worktree for which this
> branch is HEAD, or the empty string otherwise".
>
> Then the caller from git-branch (or anybody wanting to emulate it) could
> still do:
>
>   %(if)%(worktree)%(then)+ %(refname)%(end)
>
> As a bonus, the decision to use "+" becomes a lot easier. It is no
> longer a part of the format language that we must promise forever, but
> simply a porcelain decision by git-branch.

Yeah, thanks for following through the thought process to the logical conclusion. If a branch is multply checked out, which is a condition "git worktree" and "git checkout" ought to prevent from happening, we could leave the result unspecified but a non-empty string, or something like that.

> file-global data-structure storing the worktree info once (in an ideal
> world, it would be part of a "struct ref_format" that uses no global
> variables, but that is not how the code is structured today).

Yes, I agree that would be the ideal longer-term direction to move this code in.

Show 19 quoted lines

>> > +		} else if (!strcmp(name, "worktree")) {
>> > +			if (string_list_has_string(&atom->u.worktree_heads, ref->refname))
>> 
>> I thought we were moving towards killing the use of string_list as a
>> look-up table, as we do not want to see thoughtless copy&paste such
>> a code from parts of the code that are not performance critical to a
>> part.  Not very satisfying.
>> 
>> 	I think we can let this pass, and later add a wrapper around
>> 	hashmap that is meant to only be used to replace string-list
>> 	used for this exact purpose, i.e. key is a string, and there
>> 	is no need to iterate over the existing elements in any
>> 	sorted order.  Optionally, we can limit the look up to only
>> 	checking for existence, if it makes the code for the wrapper
>> 	simpler.
>
> This came up over in another thread yesterday, too. So yeah, perhaps we
> should move on that (I am OK punting on it for this series and
> converting it later, though).

FWIW, I am OK punting and leaving, too.