Now what: multiple HEAD refs

Hi,

just a heads-up for everyone tried "git pull" after using "git merge" too much:

$ git pull . ref1 HEAD (notice the space!)

will happily create refs/heads/HEAD. What happens next is not easily to understand: all files suddenly declared "New" by "git status", "git checkout" does not work, reporting "Need a single revision" (which is actually _the_ hint here).

The solution is simple: remove .git/refs/heads/HEAD

Maybe "git fsck-object" can hint on multiple HEADS?

Alex Riesen <raa.lkml@gmail.com> writes:

If you were too used to git merge, you would have wrote HEAD before ref1, so that does not sound plausible ;-).

        $ git pull . maint HEAD
        error: no such remote ref refs/heads/HEAD
        Fetch failure: .
	$ echo $?
        1

But worse yet, the above syntax is to create an Octopus, and you probably did not mean that.

I think the reason why my trial here worked correctly while you had trouble with it is because I have the send-pack fix from Pasky last night.

On 12/15/05, Junio C Hamano <junkio@cox.net> wrote:

no, that I have remembered. What I constantly forget is the space-vs-colon difference.

no, of course not.

yes, probably. It cleanups a reference if there was an error, right?

Alex Riesen <raa.lkml@gmail.com> writes:

Not really. send-pack does not have anything to do with this (it is involved in git-push not git-pull). Care to see how yours gets broken when you do "sh -x git-pull.sh . ref1 HEAD"? If .git/refs/heads/HEAD exists in the first place then I would understand it would not fail with the error message I quoted, but the original message from you indicated that "git pull" is the one that creates the breakage, and I am trying to see how.

On 12/15/05, Junio C Hamano <junkio@cox.net> wrote:

I tried. Interesting: no refs/heads/HEAD. But, then I tried "ref1:HEAD":

broken-HEAD /d/download/git2 [822]
PATH=".:$PATH" sh -x git-pull . lf-usage:HEAD
+ . git-sh-setup
++ unset CDPATH
++ : .git
++ : .git/objects
++ GIT_DIR=.git
++ git-var GIT_AUTHOR_IDENT
+ strategy_args=
+ no_summary=
+ no_commit=
+ break
++ git-rev-parse --verify HEAD
+ orig_head=5a0b59da20d832fcfdf864b522718acbc2171525
+ git-fetch --update-head-ok . lf-usage:HEAD
* refs/heads/HEAD: storing branch 'lf-usage' of .
++ git-rev-parse --verify HEAD
git-rev-parse: fatal: Needed a single revision
+ curr_head=
+ test '' '!=' 5a0b59da20d832fcfdf864b522718acbc2171525
+ echo 'Warning: fetch updated the current branch head.'
Warning: fetch updated the current branch head.
+ echo 'Warning: fast forwarding your working tree.'
Warning: fast forwarding your working tree.
+ git-read-tree -u -m 5a0b59da20d832fcfdf864b522718acbc2171525 ''
usage: git-read-tree (<sha> | -m [-u | -i] <sha1> [<sha2> [<sha3>]])
+ die 'You need to first update your working tree.'
+ echo 'You need to first update your working tree.'
You need to first update your working tree.
+ exit 1

And of course, there was refs/heads/HEAD now. So it seems that I _had_ typed it with a colon (though I'm very sure I did it with a space as well). Sorry for the whole confusion, but that reveals that other problem, which Johannes' patch partially helps with.

Alex Riesen <raa.lkml@gmail.com> writes:

That statement sounds as if "git pull . ref1:HEAD" makes some sense and you typed it without colon by mistake. But it does not make any sense to me; I am puzzled ... what are you trying to achieve with "git pull . ref1:HEAD"?

The patch from Johannes feels right but I haven't had caffeine yet, so..

On 12/15/05, Junio C Hamano <junkio@cox.net> wrote:

exactly.

merge branch ref1 into current. Is that not a correct refspec?

Hi,

On Thu, 15 Dec 2005, Alex Riesen wrote:

No, it is not correct. To pull means that you want to merge the fetched ref (your ref1), and store the result in the current branch.

But if you write "ref1:HEAD", you pretend that you want to fast-forward the local branch "HEAD" to ref1, and get an error if it is not forwardable.

In your case, I guess, "git pull ref1" is what you meant.

Hth, Dscho

On 12/15/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

I did, I guess... Confused now.