7

in my project, I usually have a (development) branch leading to the next release version at which point the development branch will be merged into the release branch, and then a new development branch will be created.

This means, two branch HEADs will be pointing to the same commit: 

$> cd project.git  
$> rgrep release .  
    ./packed-refs:2808f1de3e05bf7fcc509c20f31a93e2ba645bd3 refs/heads/release  
$> rgrep 2808f1de3e05bf7fcc509c20f31a93e2ba645bd3 .  
    ./packed-refs:2808f1de3e05bf7fcc509c20f31a93e2ba645bd3 refs/heads/release  
    ./packed-refs:2808f1de3e05bf7fcc509c20f31a93e2ba645bd3 refs/heads/development_0103

I want people who clone from my repo to automatically get a check out of the release branch. 

$> cd project.git  
$> git symbolic-ref HEAD  
    refs/heads/release

but, when cloning from that repo apparently people get the alphabetically first matching branch checked out 

$> git clone project.git/ project.clone  
$> cd project.clone  
$> git status  
    # On branch development_0103  
    nothing to commit (working directory clean)

It seems to me git is working out the branch name to check out by looking at the SHA1, but not actually using the remote's symbolic-head HEAD.

Is there any way to solve this and make the clone default to 'release' instead of 'development_0103'?

CharlesB
  • 86,532
  • 28
  • 194
  • 218
Andre D
  • 71
  • 1
  • Is there a reason you’re not using master? – Josh Lee Feb 28 '11 at 18:10
  • What version of git are you using? I've *never* seen this. – Cascabel Feb 28 '11 at 19:33
  • jleedev: there is no difference in behaviour if I rename 'release' to 'master' as 'master' still comes after 'development_0103' alphabetically – Andre D Feb 28 '11 at 19:44
  • @Andre: I don't think you've fully tested things - it's not necessarily the alphabetically first branch that ends up checked out, but you're right that there's a bug. You might want to report it to the mailing list. – Cascabel Feb 28 '11 at 20:42
  • 1
    @Andre: I went ahead and reported it to the mailing list. I can't give you a direct link yet, but it'll show up here: http://dir.gmane.org/gmane.comp.version-control.git – Cascabel Feb 28 '11 at 20:52
  • 3
    @Andre @Jefromi: the link for Jefromi's post, with answers, would be: http://comments.gmane.org/gmane.comp.version-control.git/168144 . A patch was proposed back in 2009, but not yet applied: http://article.gmane.org/gmane.comp.version-control.git/110049 – VonC Mar 01 '11 at 05:10

1 Answers1

1

You can use separate remote repository for pushing public releases instead of using your way. You will work as usual in your dev remote repo. merge stable commit to the release branch. and after that git push release_origin release. So you could share only this release_origin repo with another people.

Or there is another hack for that. :) Just rename your release branch to a_release, so it will be first alphabetically. :)

Evgen Bodunov
  • 5,438
  • 2
  • 29
  • 43