Issue #7783 invalid

Changing the default branch does not affect remote HEAD

Rich Mayfield
created an issue

My understanding is that the remote HEAD (the HEAD symbolic-ref in my Bitbucket repository) points to the head of the default branch. As such, HEAD in my Bitbucket repository resolves to the same commit as master (i.e. origin/HEAD and origin/master are the same for me).

Lets say I've created a branch "develop" and I want that branch to be the default branch. I select that as my default branch in the repository.

I would expect that the HEAD symbolic reference in my Bitbucket repository to be changed to develop and as such I should see origin/HEAD be the same as origin/develop. Instead, the reference does not change - it is still referencing master.

See also the following. Apparently changing the default branch in github manages the HEAD as I've described.

http://stackoverflow.com/questions/1485578/how-do-i-change-a-git-remote-head-to-point-to-something-besides-master/2962737

Comments (23)

  1. Rich Mayfield reporter

    I see the setting to change the main branch. I have used that to change the "\main branch however the HEAD symbolic reference does not change. The HEAD continues to reference the same commit as it did previously (when "master" was the main branch).

    E.g., let's say I have "newbranch" and it points to a commit and "master" points to a different commit. If I make newbranch the default branch, do a git fetch --all, I should see that origin/HEAD points to the newbranch's commit. It does not. It still points to the master's commit.

  2. Erik van Zijst staff

    I've had a look and I can't reproduce the behavior you're describing. On Bitbucket nor GitHub.

    I created a repo with two branches and then clone it. I can see refs/remotes/origin/HEAD correctly point to the remote "default branch", but when I then change it on Bitbucket or GitHub and fetch --all, it does not get updated locally.

    I've tested with 1.7.5.4.

    Can you provide me the exact steps you took on GitHub so I can try that?

  3. Rich Mayfield reporter

    I have not used GitHub.

    I've seen this on Bitbucket. From your description it sounds like you are seeing the same problem. After doing a fetch --all I would expect the refs/remotes/origin/HEAD to get updated locally to reference the new default branch.

    If refs/remotes/origin/HEAD is unchanged, i.e. it points to the old default branch, then git clients will determine the wrong default branch.

  4. Erik van Zijst staff

    You don't normally interact with remotes/origin/HEAD and your local HEAD is certainly not meant to track the remote one, so I'm not sure what scenario you're hinting at.

    In fact, when create a new repo locally, run git remote add origin <url>, you won't even get a remotes/origin/HEAD, but your local clone is just as usable as when you had cloned it.

  5. Rich Mayfield reporter

    If you clone a git repository, git will look at HEAD on the origin and will use that as the default branch in the clone.

    Let's say I create a local git repository with two branches ("master" and "develop"), use "git symbolic-ref HEAD refs/heads/develop", and then clone that repository the clone starts in "develop".

    # git clone a b
    # cd b
    # git branch
    * develop
    

    Basically, when someone clones a repository I want them to be dropped into the default branch "develop". I do not want them dropped into "master". In Bitbucket I have set the default branch to "develop"; however, when someone runs "git clone" they are dropped into "master" and they have to change their context to "develop". Since I'm dealing with folks new to git they may not do that.

    I guess I don't quite get why Bitbucket's "default branch" is not in some way tied with git clone's notion of a "default branch".

  6. Rich Mayfield reporter

    I guess what I'm thinking is that Bitbucket should be performing the

    git symbolic-ref HEAD refs/heads/develop
    

    when "develop" is selected as the default branch.

    This would make Bitbucket's notion of "default branch" consistent.

  7. Erik van Zijst staff

    When you clone a repo from bitbucket using git clone <url> the local clone's HEAD will really be set to what Bitbucket's main branch was at the time of the clone.

    If this is not the case for you, could you provide me with steps to reproduce this?

  8. Matthias Wiels

    I have the same problem as describer above. Main branch is set to "develop". But after cloning I'm on the master branch...

    $ git clone git@bitbucket.org:redsys/ipaper-web.git Cloning into 'ipaper-web'... remote: Counting objects: 27858, done. remote: Compressing objects: 100% (7078/7078), done. remote: Total 27858 (delta 12554), reused 27670 (delta 12414) Receiving objects: 100% (27858/27858), 9.38 MiB | 412.00 KiB/s, done. Resolving deltas: 100% (12554/12554), done. Checking connectivity... done

    $ cd ipaper-web/

    ipaper-web (master)

  9. Rich Mayfield reporter

    I had forgotten about this one. "Invalid"? Really? You guys really ought to reconsider your communications. A customer reporting a legitimate problem (one that others see as well) shouldn't be deemed "invalid".

    In any event, the behavior appears to have changed. I cloned and then ran:

    $ git branch * develop

    So it looks like it is now working for me at least.

  10. tail-f

    It is not working. I have set the "Main branch" to develop. I do a clone, and find myself on master in the clone. Repository is private.

    Very easy to reproduce.

    The desired behavior would be that:

    git clone <URL>

    and

    git clone -b develop <URL>

    would both yield the same result

  11. Dag Gruneau

    Yesterday it was not working, now it is!

    EDIT

    For some repositories it works and for some other it doesn't. It is clearly a bug not consistent behavior!

  12. Chau Duong

    I have this problem too. One of the repositories at my work place had this problem. And now, 1 out of 15 of my own repositories have this problem as well.

    On bitbucket, the develop branch was definitely set as the main branch.

    This is a very weird behavior. And based on the complaints, I believe this is a real issue. It's unlikely that we are not configuring our repo correctly in this case.

  13. Chau Duong

    Update: After a merge that makes develop different from master, the problem is now gone. I might update again when I merge develop back to master and see if this happens again.

    Cheers.

  14. Oliver Secluna

    I have the same problem. I changed the main branch in my repo. When I do a git clone, I do not always get the main branch. Sometimes I will get a different branch. If this is by design (in that the default branch for a clone is somehow based on that status of the branches in your repo rather than the main branch) it would be useful to know how it works.

  15. Log in to comment