Now what: multiple HEAD refs

Now what: multiple HEAD refs

[Alex Riesen]

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?

Re: Now what: multiple HEAD refs

[Junio C Hamano]

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

> just a heads-up for everyone tried "git pull" after using "git merge" too much:
>
> $ git pull . ref1 HEAD (notice the space!)

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.

Re: Now what: multiple HEAD refs

[Alex Riesen]

On 12/15/05, Junio C Hamano <junkio@cox.net> wrote:
> > just a heads-up for everyone tried "git pull" after using "git merge" too much:
> >
> > $ git pull . ref1 HEAD (notice the space!)
>
> If you were too used to git merge, you would have wrote
> HEAD before ref1, so that does not sound plausible ;-).

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

>         $ 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.

no, of course not.

> 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.

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

Re: Now what: multiple HEAD refs

[Junio C Hamano]

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

> On 12/15/05, Junio C Hamano <junkio@cox.net> wrote:
>> 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.
>
> yes, probably. It cleanups a reference if there was an error, right?

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.

Re: Now what: multiple HEAD refs

[Alex Riesen]

On 12/15/05, Junio C Hamano <junkio@cox.net> wrote:
> >> 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.
> >
> > yes, probably. It cleanups a reference if there was an error, right?
>
> 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"?

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.

Re: Now what: multiple HEAD refs

[Junio C Hamano]

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

> On 12/15/05, Junio C Hamano <junkio@cox.net> wrote:
>
>> >
>> > $ git pull . ref1 HEAD (notice the space!)
>>
>> If you were too used to git merge, you would have wrote
>> HEAD before ref1, so that does not sound plausible ;-).
>
> no, that I have remembered. What I constantly forget is the
> space-vs-colon difference.

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..

Re: Now what: multiple HEAD refs

[Alex Riesen]

On 12/15/05, Junio C Hamano <junkio@cox.net> wrote:
> >> >
> >> > $ git pull . ref1 HEAD (notice the space!)
> >>
> >> If you were too used to git merge, you would have wrote
> >> HEAD before ref1, so that does not sound plausible ;-).
> >
> > no, that I have remembered. What I constantly forget is the
> > space-vs-colon difference.
>
> That statement sounds as if "git pull . ref1:HEAD" makes some
> sense and you typed it without colon by mistake.  But it does

exactly.

> not make any sense to me; I am puzzled ... what are you trying
> to achieve with "git pull . ref1:HEAD"?

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

Re: Now what: multiple HEAD refs

[Johannes Schindelin]

Hi,

On Thu, 15 Dec 2005, Alex Riesen wrote:

> > not make any sense to me; I am puzzled ... what are you trying
> > to achieve with "git pull . ref1:HEAD"?
> 
> merge branch ref1 into current. Is that not a correct refspec?

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

Re: Now what: multiple HEAD refs

[Alex Riesen]

On 12/15/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > not make any sense to me; I am puzzled ... what are you trying
> > > to achieve with "git pull . ref1:HEAD"?
> >
> > merge branch ref1 into current. Is that not a correct refspec?
>
> 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.

I did, I guess...
Confused now.