name-rev: anchor pattern without --exclude?

Hello,

I'm trying to restrict name-rev's output to a ref whose name begins with the supplied pattern [*]. Looking at "man git-name-rev", builtin/name-rev.c, and wildmatch.c, I don't see a way to accomplish this with "--refs=<pattern>".

Say, for example, that I want to limit name-rev's output to a ref in the "refs/heads/" namespace.

    * cc8f7dc (master) c
    * ad6d6f0 b
    | * 49a2156 (refs/wip/wtree/refs/heads/master) d
    |/  
    * b91f97a a

    --------------------------------------------------

    $ git name-rev b91f97a
    b91f97a wip/wtree/refs/heads/master~1

    $ git name-rev --refs="refs/heads/*" b91f97a
    b91f97a wip/wtree/refs/heads/master~1

    $ git name-rev --refs="^refs/heads/*" b91f97a
    b91f97a undefined

Starting with v2.13.0, I can get my desired output using the --exclude option.

    $ git name-rev --refs="refs/heads/*" --exclude="*/refs/heads/*" b91f97a
    b91f97a master~2

But, unfortunately, I'm trying to find a solution that works with earlier Git versions (back to v1.9.4).

Am I overlooking a way to do this without the --exclude option?

[*] A bit more information on why I'm trying to do this: In Magit, we
    have a work-in-progress feature that takes "snapshots" of changes
    before they are committed.  These snapshots are stored as
    "refs/wip/{wtree,index}/<full refname>".

    We want to use name-rev to map a commit to a name in "refs/heads/",
    ignoring these snapshot refs.

Kyle Meyer <kyle@kyleam.com> writes:

What is the <full refname> in the above supposed to represent? When a user sees two refs "refs/wip/{wtree,index}/<full refname>", does it mean: "These two represent a snapshot for changes while the user was working on this branch"?

Isn't name-rev a wrong tool to find that information? What is the answer desired by your application when two or more branches point at the same commit you are interested in? Pick one at random? An error saying it cannot decide where to place the snapshot?

I am wondering if you are looking for "symbolic-ref HEAD".

Junio C Hamano <gitster@pobox.com> writes:

It's the current branch, as returned by "git symbolic-ref HEAD".

Yes.

Sorry for the confusion. We're using "symbolic-ref HEAD" to get the above information. I was just trying to explain why we're dealing with ref names that contain a "refs/heads" substring (like refs/wip/wtree/refs/heads/master in the example I gave).

Our use of name-rev is just to get a friendly name for a hash. If two branches point to the same commit, we're fine with whatever decision "git name-rev" makes; we just want to limit it to refs in the "refs/heads/" namespace.

On Thu, Jul 6, 2017 at 10:23 AM, Kyle Meyer <kyle@kyleam.com> wrote:

If you don't need the ancestor traversals "git name-rev" provides, "git for-each-ref --count 1 --format "%(refname:short)" --points-at <hash> refs/heads/" might work. That only goes back to Git 2.7.0, though; still quite a ways off your 1.9 target. ("git branch --points-at" does the same thing, I should add, and only for branches, but you can't directly limit its output like you can with "for-each-ref".. Perhaps that doesn't matter for your use case.) If you want names like "master~2", from your example, though, "--points-at" won't do what you need.

Bryan

Bryan Turner <bturner@atlassian.com> writes:

[...]

Thanks for the suggestion. Unfortunately, I do want to consider names like "master~2". I was just hoping that I had overlooked another way to achieve the

    git name-rev --refs="refs/heads/*" --exclude="*/refs/heads/*" <commit>

example I gave in my initial post.