Thanks a lot for this answer.
I've also read the man page of check-ref-format. However, there may be
some not up-to-date documentation or some "non guarded against"
command usage in git.
This explains the second part of my question ("Or maybe this command
(ie. check-ref-format) is not intended to deal with symbolic links
?").
Another possibility would be that only git internal symbolic
references are allowed to live under the ".git" dir (HEAD, FETCH_HEAD,
...) and that user defined symrefs should live under refs/. In this
case, maybe "git symbolic-ref" should also prevent the user from
creating a reference which doesn't contains a forward slash.
Once again, by reading at the code I can understand how those commands
currently work. What I'm trying to achieve is to understand what
should be their recommended usage.
Of course, I'll be glad to contribute any code/doc patch once the
"voice of the git community" has spoken :-)
Em.
On Tue, Feb 15, 2011 at 4:19 AM, Kevin Ballard <kevin@xxxxxx> wrote:
> On Feb 14, 2011, at 12:58 PM, Emeric Fermas wrote:
>
>> - As check-ref-format fails when being passed "first", does this mean
>> that it's not recommended to create a symbolic reference at the same
>> level than "HEAD"? Or maybe this command is not intended to deal with
>> symbolic links ?
>
> I don't know about the rest of your question, but check-ref-format
> explicitly states in the manpage that the refname must have at least
> one /, to enforce the presence of a category (such as heads/) in the
> refname.
>
> -Kevin Ballard
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html