Show 47 quoted lines
> On Wed, Oct 25, 2023 at 03:44:33PM +0100, Phillip Wood wrote:
>> On 25/10/2023 15:26, Han-Wen Nienhuys wrote:
>>> On Tue, Oct 24, 2023 at 9:17 PM Junio C Hamano <gitster@pobox.com> wrote:
>>>>
>>>> Patrick Steinhardt <ps@pks.im> writes:
>>>>
>>>>> this patch series introduces a new `--exists` mode to git-show-ref(1) to
>>>>> explicitly check for the existence of a reference, only.
>>>>
>>>> I agree that show-ref would be the best place for this feature (not
>>>> rev-parse, which is already a kitchen sink). After all, the command
>>>> was designed for validating refs in 358ddb62 (Add "git show-ref"
>>>> builtin command, 2006-09-15).
>>>>
>>>> Thanks. Hopefully I can take a look before I go offline.
>>>
>>> The series description doesn't say why users would care about this.
>>>
>>> If this is just to ease testing, I suggest adding functionality to a
>>> suitable test helper. Anything you add to git-show-ref is a publicly
>>> visible API that needs documentation and comes with a stability
>>> guarantee that is more expensive to maintain than test helper
>>> functionality.
>>
>> Does the new functionality provide a way for scripts to see if a branch is
>> unborn (i.e. has not commits yet)? I don't think we have a way to
>> distinguish between a ref that points to a missing object and an unborn
>> branch at the moment.
>
> You could do it with two commands:
>
> ```
> target=$(git symbolic-ref HEAD)
> git show-ref --exists "$target"
> case "$?" in
> 2)
> echo "unborn branch";;
> 0)
> echo "branch exists";;
> *)
> echo "could be anything, dunno";;
> esac
> ```
>
> While you could use git-rev-parse(1) instead of git-show-ref(1), you
> wouldn't be able to easily distinguish the case of a missing target
> reference and any other kind of error.