AW: specifying revision - how to enforce matching a tag/branch-name or revision only

From: Boettger, Heiko <heiko.boettger@karlstorz.com>
Date: Jun 25, 2019, 14:35 UTC
Message-ID: <8C0042D8869AEA4AA334B49AFBBCEF82024806510C@TUT-EX01-PV.KSTG.corp>
In-Reply-To: <CACsJy8CBQhF2=nZ4tZj_h6Gr8PjK3amANjT38uhnurS0dehyiQ@mail.gmail.com>

First of all many thanks for the responses.

And yes refs/heads/foo-g<hash> will be interpreted by "git checkout" as "git-describe" output, if there is no such branch. My current solution for the moment is to extract the commit-sha1 from the output of "git for-each-ref" and fail if there is no exact match otherwise git checkout will anyway do what I want, because it finds the branch.

Regards Heiko

________________________________________
Von: Duy Nguyen [pclouds@gmail.com]
Gesendet: Dienstag, 25. Juni 2019 13:43
An: Junio C Hamano
Cc: Kyle Meyer; Boettger, Heiko; git@vger.kernel.org
Betreff: Re: specifying revision - how to enforce matching a tag/branch-name or revision only

On Fri, Jun 21, 2019 at 10:16 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 7 quoted lines

>
> Kyle Meyer <kyle@kyleam.com> writes:
>
> >> git rev-parse "${BRANCH_NAME}"  || git rev-parse "refs/remotes/${UPSTREAM}/${BRANCH_NAME}"
> >>
> >> Unfortunately somebody used the branch name "add-gcc10" and `git rev-parse` which didn't exist on one repository. However `git rev-parse`
> >> also supports to parse the `git-describe` format which resulted in checkout a commit starting with "cc10".

I wonder if something like refs/heads/foo-g<hash> could trip the parser and mistake it as a `git-describe` output. Staring at get_describe_name() alone the answer might be an unfortunate "yes". But maybe something will kick in earlier and reject it.

> >
> > Can't you prepend "refs/heads/" to BRANCH_NAME to disambiguate?
>
> Yes, that is the kosher way for most commands.

Some commands always prepend refs/heads/ to the <branch> argument you give it if I remember correctly. Or I think I accidentally made refs/heads/refs/heads/something once with some command (then hell ensued). If true, prepending refs/heads/ is not really foolproof.

Show 6 quoted lines

> It gets a bit tricky for "checkout <branch-or-committish>" that
> changes its behaviour (a local branch is checked out and the next
> commit extends it, other committishes like tags and remote-tracking
> branch tips are checked out on a detached HEAD), and has special
> rules for a "${BRANCH_NAME}" that is both the name of a local branch
> and something else.

I think "git checkout --no-guess --no-detach <branch>" should only accept a branch (i.e. ref: refs/heads/<branch>). Dropping --no-detach should allow any ref, which interprets refs/heads/foo as an absolute ref, not as refs/heads/refs/heads/foo.

> Hopefully (Duy Cc'ed) "git switch" would improve the situation.

"git switch" has slightly saner defaults, but with --guess being default to be friendlier to interactive usage, it's still not that much friendlier to scripts, unfortunately. -- Duy