I might be a bit late, but I will try to answer to two comments from ieure:
1. What I was trying to explain is that this particular line in your bug description is incorrect:
"Rather than "git checkout gold/master", it finds the hash of gold/master and checks out that instead. This is the root of the problem."
You're making the same mistake when you're saying: "Building with a detached head is a good thing, except it's absolutely the same as not? That nonsensical."
I didn't say that being in detached HEAD state is the same as not being in it. I said that both actions "git checkout gold/master" and "git checkout SHA-1" are having the same effect. Generally speaking, checkout to any remote branch (for example like origin/master) is ABSOLUTELY identical to checking out to SHA-1 this branch points to (actually, it is true for any SHA-1 commit ID). BOTH actions will lead to detached HEAD, which means that the HEAD will be pointing to the commit ID directly, it won't be pointing to the branch, i.e. it won't be a symbolic ref anymore.
You can take a look at it like this in any repo:
$ git checkout master
$ vi .git/HEAD
$ git rev-parse master
$ git checkout "SHA-1 from previous command" # (it will printout pretty much the same explanation as i'm trying to make here)
$ vi .git/HEAD #it is now pointing directly to a commit
2. Secondly, why working in Hudson with detached HEAD is good? Because the detached HEAD state will guarantee you that NONE of the actions your performing in this state will be recorded in the LOCAL repo unless you will be explicit about it. For example, in detached HEAD state you can commit, but your commits will be lost as soon as you will checkout to an existing local branch, unless you will create a new local branch after you committed in detached HEAD state.
You're saying that the problem is that your Hudson local repo is in broken state after build. Well, it is not, because detached HEAD is not a broken state! Why you shouldn't care about local Hudson repo? Exactly, because git plugin is working with it using detached HEAD state.
here is the example:
you have your gold/master branch pointing to commit aaa
you have your dev branch pointing to commit bbb
build process checks out to gold/master revision aaa
then it resolves the revision to merge bbb and performs the merge. Your HEAD is pointing to the resulting revision ccc (for example there was a recursive merge used which got recorded as new commit) and gets tagged. Now when you take a look at the help message for the git publisher branches you will see that it says that it will merge back the current HEAD! to the specified remote branch!
I.e. that you will get the merge results in your official repository just fine, unless, for example, there is a conflict during the merge.
The point is that you don't have to care about the state of your local Hudson repository, becasue it is not important - your mainline (gold) is important.
OTOH I understand it might be necessary for you to be in some branch because git-buildpackage is requiring it. We are using the default detached HEAD behavior for integration builds, but we use Release plugin in order to prepare production artifact, which has explicit instructions to checkout to master branch, pull latest changes from mainline and then build the code.
I hope that helps.
You're mistaken. Checking out to gold/master is actually ABSOLUTELY the same action as checking out to revision it points to. It is a "remote" branch so checking out to it will lead to detached HEAD no matter what.
Git plugin working with revisions in detached HEAD mode is a good thing, IMHO.
It would be more interesting to see the log when it tries to push back your changes to understand why you're not happy about it.