Junio C Hamano <[email protected]> writes:
> Kyle Meyer <[email protected]> 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
