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@xxxxxxxxx> wrote:
> > >
> > > Patrick Steinhardt <ps@xxxxxx> 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.
Patrick
Attachment:
signature.asc
Description: PGP signature
