Am 28.06.2013 14:18, schrieb Fredrik Gustafsson:
> On Fri, Jun 28, 2013 at 01:59:51PM +0200, Stefan Näwe wrote:
>> Hi there!
>> Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)
>> or a tag (from refs/tags/) ?
>> Background: At $dayjob we're using some kind of 'hidden' refs (in 
>> refs/releases/)
>> to communicate between the 'branch integrator' (who creates the ref in 
>> refs/releases/)
>> and the 'build master' who wants to build that ref. 
>> It would be a little easier if the build master could simply say
>>   git clone -b refs/releases/the-release-for-today URL
>> instead of: git clone... ; cd ... ; git fetch... ; git checkout....
>> Any answer or even a better idea to solve that is appreciated.
>> Stefan
> I don't understand what the alternative should be. You can't look in
> /refs/* because there's a lot of other stuff like bisect/remotes etc.
> there.

Well, I tell clone exactly what I want. There is no reason try something
from refs/*.
> Of course you could add to also look in /refs/releases/ but as I
> understand you that a special solution for your company. Why should all
> git users have that addition?

It wouldn't hurt, IMHO. Maybe it would even make sense to allow any SHA-1
to be passed to '-b'.
> Two questions about your setup:
>       1. Why do you always clone your repository? To me clone is a one
>       time operation.

We would use 'git archive' if that would be submodule-aware...

>       2. Why don't you tag your releases with an ordinary tag?

Because we use that 'refs/release' thing as a hidden ref that other
developers will not see when they fetch (unless they are told to checkout
that particular ref).

Think of using this similar to the way github uses refs/pull/*/{head,merge} 
for their pull request mechanism.

/dev/random says: The Definition of an Upgrade: Take old bugs out, put new ones 
python -c "print 
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to