On 3/9/2014 12:54 PM, Carlos Pereira wrote:
On 03/09/2014 07:46 AM, Torsten Bögershausen wrote:
After creating a local repository with these two branches, and a
server repository with git init --bare, and pushing the two branches:
> > git remote add originfoo@bar:~/path/test.git
> git push origin master-g
> git push origin master-x
> > everything seems fine, but cloning:
> git clonefoo@bar:~/path/test.git
> terminates with a warning: remote HEAD refers to nonexistent ref,
unable to checkout.
This is because Git is trying to be nice:
When you clone, it tries to checkout a branch for you.
What happens when you only have 1 branch, lets say master-x?
If I clone the bare repo here, with only 1 branch, this branch
is automatically checked out (tested on 1.8.5.2)
What happens when you have 2 branches on the server?
Git really can not make a decision which one is the right one to
check out for
you, so if you have 2 branched like "master" and "develop", it checks
out the
"master" branch for you.
But if you have "master-x" and "master-g" then Git has no clue, which
one could
be you favorite one (and neither have I)
The problem is on the server repo, the cloned repo is just a
consequence. After initializing the server repo and pushing two
branches master-g and master-x there is no master branch. Therefore
the HEAD file should not point to a master branch that does not exist:
ref: refs/heads/master
It could point to master-g (the first branch to be pushed) or master-x
(the last branch to be pushed), depending of the criterion used by
git, but pointing to something that does not exist seems weird and is
the cause of the further complaints when the whole repository is
cloned...
There is a "git remote set-head" to manipulate HEAD in a remote repository.
The fact that it is not set when you push master-x and master-y could be
justified to some extent.
I think that this only applies to a case when you are pushing into a
repository that have no branches.
Consider that you do not have to push only one branch, you may push any
set of branches you want. And I do not think that branches in the set
have any meaningful order.
Also, your local HEAD does not necessary point to the "most reasonable
branch to checkout when you clone". It is just your current branch.
Now the questions is, how should the remote repository determine what to
change HEAD to?
I agree that this might be viewed as a user experience issue.
But I can not come up with a possible solution. Can you?
I forgot to say that the git version is 1.7.2.5 in both the initial
repo and the server repo (probably this issue was fixed in newer
versions?)
As I said, editing directly the HEAD text file on the server, and
replacing master by master-g (or master-x) seems to solve the problem.
My question is: is that enough? or shall I expect further issues down
the road?
I do not think there should be any issues.
Basically if your repository is not using master as the "most reasonable
branch to checkout when you clone" you need to do "git remote set-head"
when you are preparing the shared repository.
I guess that in most setups there will be just one shared repository.
--
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