Community
Participate
Working Groups
Steps: 1. Clone a repo 2. Create a new branch 3. Push it with the "--all" option 4. Clone the same repo again, to a different location => SHOULD BE: the current branch in the second repo = "master" => IS: the branch created in 2.
A failing test case: http://egit.eclipse.org/r/4675
I'm seeing the same behavior using the Git command-line
Here is a minimal chain of commands I use to reproduce it in the Git CLI: mkdir repo;cd repo;git init --bare;cd ..;git clone repo clone1;cd clone1;echo "f" > f;git add .;git commit -m 'init';git branch a;git push --all;cd ..;git clone repo clone2;cd clone2;git branch The result of the last one is: * master
I'm not sure this is related to the --all option. It looks like the JGit CloneCommand uses the first ref matching head to check out when cloning, while the command line makes a special case for master if multiple advertised refs that match head are found. https://github.com/git/git/blob/b7f9bbd8754110b18535c5df293c3cb70a023e18/remote.c#L1579-1583 I pushed a change http://egit.eclipse.org/r/#change,4687 that special cases master similarly in JGit
(In reply to comment #4) > I pushed a change http://egit.eclipse.org/r/#change,4687 that special cases > master similarly in JGit Cool, the testCloneRepositoryWithMultipleHeadBranches test you added looks like a better version of my test from http://egit.eclipse.org/r/#change,4675. Is it ok to abandon the latter?
> Is it ok to abandon the latter? I think it is
Done. I've changed the summary so it matches with your change's name. The change has been merged, I'm matching the bug as fixed. Thanks Kev.
