Jeff King <p...@peff.net> writes:
>> 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.
>> > + } 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.
