Is there any reason why 'git clone -b' only takes a branch or a tag

Question

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.

Answer 1

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.

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?

Two questions about your setup:
1. Why do you always clone your repository? To me clone is a one time operation.
2. Why don't you tag your releases with an ordinary tag?

Comments

   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.