Re: name-rev: anchor pattern without --exclude?

From: Kyle Meyer <kyle@kyleam.com>
Date: Jul 6, 2017, 17:23 UTC
Message-ID: <87h8yptr7t.fsf@kyleam.com>
In-Reply-To: <xmqqfue9fqfe.fsf@gitster.mtv.corp.google.com>

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

Show 11 quoted lines

> Kyle Meyer <kyle@kyleam.com> writes:
>
>> [*] 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.
>
> What is the <full refname> in the above supposed to represent?

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

> 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"?

Yes.

> Isn't name-rev a wrong tool to find that information?

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).

> 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?

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.

-- 
Kyle