fixing update_head in gitlab_projects for issue#5408 (at gitlabhq/gitlabhq)

[mecp]

Please have a look at discussion this issue https://github.com/gitlabhq/gitlabhq/issues/5408 in gitlabhq/gitlabhq.

Although this fix is enough for the part which gitlab_shell is doing, but after changing the default branch in project settings if you directly goto Files or Commits, the selected branch in dropdown is still the old one. So if you goto project home once and come back to Files or Commits then selected branch in dropdown is updated to default one. And I think this has to do something with updating project model about the default_branch.

Here Line#169..172 might be unnecessary, these lines just check if this command executes successfully. And then actually checks the output of git show-ref if it is empty or not.

My apologies in advance if there is some mistake, as I never programmed/touched ruby before and these few lines are my first attempt.

[coveralls]

Coverage decreased (-1.15%) when pulling 9be175f on mecp:fix_default_branch_update into 2c238b7 on gitlabhq:master.

[mecp]

Ahh.. tests failed in the build, sorry I didn't run the tests before submitting the PR.

[mecp]

But it seems that the test is actually creating a dummy file in refs/heads/ and no actual branch is created. So test should actually reflect the real scenario, by checking two cases when branch exists and when it doesn't.

I guess when git clone --bare is used, refs are packed in packed-refs file which cannot be unpacked with some simple command/method.

But to update the ref in bare repo git symbolic-ref could be used which checks refs at both places in refs/heads/ dir and packed-refs file. So it can successfully update the HEAD.

In my code I have tried to check existence of ref using git show-red.

So I will update the test and make another PR later.

[coveralls]

Coverage remained the same when pulling 9be175f on mecp:fix_default_branch_update into 2c238b7 on gitlabhq:master.