threads / discuss / 17282

Deleting remote branch pointed by remote HEAD

Subject: Deleting remote branch pointed by remote HEAD

## tl;dr

24 messages between Jan 21, 2009 and Mar 12, 2009.

replies: 23people: 9as markdown or json

Marc-André Lureau· Jan 21, 2009, 13:02 UTC · lore
Hi

I deleted a remote branch which was pointed by HEAD, this way: "git push origin :master"

Then for almost every git command, I get this error: "error: refs/remotes/origin/HEAD points nowhere!".

I found this situation non-friendly. Fortunately, I could understand what's going on. But a new user might be confused.

Shouldn't the remote HEAD branch be updated or "protected" in some ways? Or should the "error" be considered as a "warning" (silently?)

What do you think?
regards,
-- 
Marc-André Lureau
Michael J Gruber· Jan 21, 2009, 14:33 UTC · re: Marc-André Lureau · lore

Re: Deleting remote branch pointed by remote HEAD

Marc-André Lureau venit, vidit, dixit 21.01.2009 14:02:
Show 7 quoted lines
> Hi
> 
> I deleted a remote branch which was pointed by HEAD, this way: "git
> push origin :master"
> 
> Then for almost every git command, I get this error: "error:
> refs/remotes/origin/HEAD points nowhere!".
You're talking about about the remote git repo, aren't you?
Show 7 quoted lines
> I found this situation non-friendly. Fortunately, I could understand
> what's going on. But a new user might be confused.
> 
> Shouldn't the remote HEAD branch be updated or "protected" in some
> ways? Or should the "error" be considered as a "warning" (silently?)
> 
> What do you think?

I think that git said "warning: updating the currently checked out branch; this may cause confusion, as the index and working tree do not reflect changes that are now in HEAD." after your push and that this may have rung some bells. I also think that pushing to a non-bare remote repo (one with a worktree checked out) is strongly advised against in multiple places, unless you know what you're doing - which you seem to do since you were able to restore your HEAD ;)

Cheers, Michael

Marc-André Lureau· Jan 21, 2009, 14:38 UTC · re: Michael J Gruber · lore

Re: Deleting remote branch pointed by remote HEAD

On Wed, Jan 21, 2009 at 4:33 PM, Michael J Gruber <git@drmicha.warpmail.net> wrote:

Show 11 quoted lines
> Marc-André Lureau venit, vidit, dixit 21.01.2009 14:02:
>> Hi
>>
>> I deleted a remote branch which was pointed by HEAD, this way: "git
>> push origin :master"
>>
>> Then for almost every git command, I get this error: "error:
>> refs/remotes/origin/HEAD points nowhere!".
>
> You're talking about about the remote git repo, aren't you?
>
Sure. But the error is on the local repo.
Show 12 quoted lines
>> I found this situation non-friendly. Fortunately, I could understand
>> what's going on. But a new user might be confused.
>>
>> Shouldn't the remote HEAD branch be updated or "protected" in some
>> ways? Or should the "error" be considered as a "warning" (silently?)
>>
>> What do you think?
>
> I think that git said
> "warning: updating the currently checked out branch; this may cause
> confusion,
> as the index and working tree do not reflect changes that are now in HEAD."

IIRC, it only says so if your local repo is on a branch tracking this remote. At least, in some conditions, I didn't get this warning. When I did second simple testing with git.git version, I also had this warning.

Show 5 quoted lines
> after your push and that this may have rung some bells. I also think
> that pushing to a non-bare remote repo (one with a worktree checked out)
> is strongly advised against in multiple places, unless you know what
> you're doing - which you seem to do since you were able to restore your
> HEAD ;)
Isn't HEAD also on non-bare repo, to indicate what is the default branch?
thanks,
-- 
Marc-André Lureau
Michael J Gruber· Jan 21, 2009, 15:24 UTC · re: Marc-André Lureau · lore

Re: Deleting remote branch pointed by remote HEAD

Marc-André Lureau venit, vidit, dixit 21.01.2009 15:38:
Show 14 quoted lines
> On Wed, Jan 21, 2009 at 4:33 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Marc-André Lureau venit, vidit, dixit 21.01.2009 14:02:
>>> Hi
>>>
>>> I deleted a remote branch which was pointed by HEAD, this way: "git
>>> push origin :master"
>>>
>>> Then for almost every git command, I get this error: "error:
>>> refs/remotes/origin/HEAD points nowhere!".
>> You're talking about about the remote git repo, aren't you?
>>
> 
> Sure. But the error is on the local repo.

So, you get these errors on the local repo when dealing with the remote repo, right? I guess this means two things:

1) You are deleting a remote branch
2) Your original report could have been a bit more detailed ;)

In fact, I'm still unsure about your setup and can't reproduce, unless "almost every git command" was vastly exaggerated, and Adeodato's description matches your setup. Does it?

If yes then git has basically no choice, unless you want git to leave HEAD in place as a detached head. This is related to how the symref is resolved, which in turn is related to the issue of removing remote branches, which in turn is related to an issue I've been meaning to look into quite a while ago... So, reproducibility would be nice.

Cheers, Michael

Marc-André Lureau· Jan 21, 2009, 15:41 UTC · re: Michael J Gruber · lore

Re: Deleting remote branch pointed by remote HEAD

Hi

On Wed, Jan 21, 2009 at 5:24 PM, Michael J Gruber <git@drmicha.warpmail.net> wrote:

Show 11 quoted lines
> So, you get these errors on the local repo when dealing with the remote
> repo, right? I guess this means two things:
>
> 1) You are deleting a remote branch
>
> 2) Your original report could have been a bit more detailed ;)
>
> In fact, I'm still unsure about your setup and can't reproduce, unless
> "almost every git command" was vastly exaggerated, and Adeodato's
> description matches your setup. Does it?
>
It matches. Sorry if I didn't describe the problem correctly.

"almost every git command" might be exaggerated. Since I am using bash and abusing completion, I get it in the middle of my shell, and it confuses bash. I have to clear my terminal to continue writing my command (C-l)

Show 5 quoted lines
> If yes then git has basically no choice, unless you want git to leave
> HEAD in place as a detached head. This is related to how the symref is
> resolved, which in turn is related to the issue of removing remote
> branches, which in turn is related to an issue I've been meaning to look
> into quite a while ago... So, reproducibility would be nice.

Not sure I follow, but I think Adeodato mail gives you a more detailed test case to reproduce.

thanks,
-- 
Marc-André Lureau
Jeff King· Jan 21, 2009, 16:19 UTC · re: Michael J Gruber · lore

Re: Deleting remote branch pointed by remote HEAD

On Wed, Jan 21, 2009 at 04:24:56PM +0100, Michael J Gruber wrote:
> So, you get these errors on the local repo when dealing with the remote
> repo, right? I guess this means two things:
> 
> 1) You are deleting a remote branch

Actually, he doesn't have to delete the remote branch; somebody else can. The problem is that the HEAD pointer for his remote tracking branches points to a branch that doesn't exist. This can happen because we sometimes update the tracking branches (including deletion) without impacting the HEAD pointer.

There are two ways that I can think of (and there may be more) to provoke this:

  1. delete a remote branch via push. The local side will helpfully
     delete your local tracking branch to match what happened on the
     remote. If it was the remote's HEAD, then you get a broken state
     (and while we discourage pushing to the remote HEAD on a non-bare
     repo, it is perfectly OK for a bare one).
  2. somebody else deletes the remote branch that is the HEAD, and you
     update your tracking branches via "git remote prune", which deletes
     your tracking branches corresponding to any deleted remote branches.

And actually there is a slight variant on both of the above. The deleted branch does not actually have to be the current HEAD on the remote. It just has to match your _idea_ of the current HEAD on the remote, which may be out of date.

Situation (1) happens entirely locally. So it can be fixed fairly easily by checking whether the remote tracking HEAD points to a branch we are deleting, and deleting the HEAD in that case (the code should be in builtin-send-pack.c:update_tracking_ref). Of course you have probably also created a broken situation on the remote, so perhaps receive-pack should handle that.

Situation (2) could do something similar: when we see that we are about to delete the ref pointed to by the remote tracking HEAD, we could delete the HEAD.

But both situations are a little hack-ish to me. You are deleting the HEAD because you don't know what the right value is from the remote end. A better fix would be to actually pull the HEAD information down during fetch. And I seem to recall a patch about that at some point (it required a new protocol extension), but I don't know what become of it.

However, even if we kept the tracking HEAD totally in sync with the remote's HEAD, it still may be possible that the remote HEAD is broken. In which case it might be nice to detect that when pulling it down and just leave the tracking HEAD unset.

-Peff
Daniel Barkalow· Jan 21, 2009, 18:30 UTC · re: Jeff King · lore

Re: Deleting remote branch pointed by remote HEAD

On Wed, 21 Jan 2009, Jeff King wrote:
Show 47 quoted lines
> On Wed, Jan 21, 2009 at 04:24:56PM +0100, Michael J Gruber wrote:
> 
> > So, you get these errors on the local repo when dealing with the remote
> > repo, right? I guess this means two things:
> > 
> > 1) You are deleting a remote branch
> 
> Actually, he doesn't have to delete the remote branch; somebody else
> can. The problem is that the HEAD pointer for his remote tracking
> branches points to a branch that doesn't exist. This can happen because
> we sometimes update the tracking branches (including deletion) without
> impacting the HEAD pointer.
> 
> There are two ways that I can think of (and there may be more) to
> provoke this:
> 
>   1. delete a remote branch via push. The local side will helpfully
>      delete your local tracking branch to match what happened on the
>      remote. If it was the remote's HEAD, then you get a broken state
>      (and while we discourage pushing to the remote HEAD on a non-bare
>      repo, it is perfectly OK for a bare one).
> 
>   2. somebody else deletes the remote branch that is the HEAD, and you
>      update your tracking branches via "git remote prune", which deletes
>      your tracking branches corresponding to any deleted remote branches.
> 
> And actually there is a slight variant on both of the above. The deleted
> branch does not actually have to be the current HEAD on the remote. It
> just has to match your _idea_ of the current HEAD on the remote, which
> may be out of date.
> 
> Situation (1) happens entirely locally. So it can be fixed fairly easily
> by checking whether the remote tracking HEAD points to a branch we are
> deleting, and deleting the HEAD in that case (the code should be in
> builtin-send-pack.c:update_tracking_ref). Of course you have probably
> also created a broken situation on the remote, so perhaps receive-pack
> should handle that.
> 
> Situation (2) could do something similar: when we see that we are about
> to delete the ref pointed to by the remote tracking HEAD, we could
> delete the HEAD.
> 
> But both situations are a little hack-ish to me. You are deleting the
> HEAD because you don't know what the right value is from the remote end.
> A better fix would be to actually pull the HEAD information down during
> fetch. And I seem to recall a patch about that at some point (it
> required a new protocol extension), but I don't know what become of it.

The information is available already; the only thing is that we don't have a way to know that the user wants to get the remote's suggested HEAD; as Junio pointed out at the time, a user might decide that "next" is the most interesting branch, and set refs/remotes/origin/HEAD to that branch, and therefore doesn't want it reset to the remote server's value.

That is, refs/remotes/origin/HEAD is only there to let the user abbreviate the most useful branch of the remote; there's no reason it should reflect the remote's HEAD, except that the remote's HEAD is a good guess if the user hasn't said anything.

I think it might be more appropriate to just care less about a broken symref, explain what's wrong if the user actually tries to use it, and otherwise mostly ignore it.

	-Daniel
*This .sig left intentionally blank*
Boyd Stephen Smith Jr.· Jan 21, 2009, 19:09 UTC · re: Daniel Barkalow · lore

Re: Deleting remote branch pointed by remote HEAD

On Wednesday 21 January 2009, Daniel Barkalow <barkalow@iabervon.org> wrote about 'Re: Deleting remote branch pointed by remote HEAD':

>I think it might be more appropriate to just care less about a broken
>symref, explain what's wrong if the user actually tries to use it, and
>otherwise mostly ignore it.

That sounds reasonable. It's not like "find" complains about every broken symlink it sees. Simple traversal or the repository should probably not complain about every broken symref.

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/
Jeff King· Jan 21, 2009, 19:12 UTC · re: Daniel Barkalow · lore

Re: Deleting remote branch pointed by remote HEAD

On Wed, Jan 21, 2009 at 01:30:10PM -0500, Daniel Barkalow wrote:
Show 10 quoted lines
> The information is available already; the only thing is that we don't have 
> a way to know that the user wants to get the remote's suggested HEAD; as 
> Junio pointed out at the time, a user might decide that "next" is the most 
> interesting branch, and set refs/remotes/origin/HEAD to that branch, and 
> therefore doesn't want it reset to the remote server's value.
> 
> That is, refs/remotes/origin/HEAD is only there to let the user abbreviate 
> the most useful branch of the remote; there's no reason it should reflect 
> the remote's HEAD, except that the remote's HEAD is a good guess if the 
> user hasn't said anything.
Good point. It is probably wrong to just fetch it without asking, then.
> I think it might be more appropriate to just care less about a broken 
> symref, explain what's wrong if the user actually tries to use it, and 
> otherwise mostly ignore it.

I thought about that, but I still wonder if deleting it when the pointed-to ref is deleted might be more convenient. Remember that "refs/remotes/$foo/HEAD" can be accessed by a shorthand "$foo". So that means it can impact ref ambiguity lookup. I guess the chance of that happening is fairly unlikely, though.

-Peff
Jeff King· Jan 21, 2009, 19:14 UTC · re: Jeff King · lore

Re: Deleting remote branch pointed by remote HEAD

On Wed, Jan 21, 2009 at 02:12:19PM -0500, Jeff King wrote:
Show 9 quoted lines
> > I think it might be more appropriate to just care less about a broken 
> > symref, explain what's wrong if the user actually tries to use it, and 
> > otherwise mostly ignore it.
> 
> I thought about that, but I still wonder if deleting it when the
> pointed-to ref is deleted might be more convenient. Remember that
> "refs/remotes/$foo/HEAD" can be accessed by a shorthand "$foo". So that
> means it can impact ref ambiguity lookup. I guess the chance of that
> happening is fairly unlikely, though.

Not to mention that even without others refs with matching names, it is probably nicer to the user who does try to access it via "$foo" to simply say "there is no $foo" rather than a confusing error message about a deleted branch that they have to manually fix. And that is easily accomplished by deleting such a bogus symref.

-Peff
Daniel Barkalow· Jan 21, 2009, 19:50 UTC · re: Jeff King · lore

Re: Deleting remote branch pointed by remote HEAD

On Wed, 21 Jan 2009, Jeff King wrote:
Show 17 quoted lines
> On Wed, Jan 21, 2009 at 02:12:19PM -0500, Jeff King wrote:
> 
> > > I think it might be more appropriate to just care less about a broken 
> > > symref, explain what's wrong if the user actually tries to use it, and 
> > > otherwise mostly ignore it.
> > 
> > I thought about that, but I still wonder if deleting it when the
> > pointed-to ref is deleted might be more convenient. Remember that
> > "refs/remotes/$foo/HEAD" can be accessed by a shorthand "$foo". So that
> > means it can impact ref ambiguity lookup. I guess the chance of that
> > happening is fairly unlikely, though.
> 
> Not to mention that even without others refs with matching names, it is
> probably nicer to the user who does try to access it via "$foo" to
> simply say "there is no $foo" rather than a confusing error message
> about a deleted branch that they have to manually fix. And that is
> easily accomplished by deleting such a bogus symref.

I think the ideal thing is to keep the symref as a reminder and just give a non-confusing error message instead of a confusing one. E.g.:

""" $foo is set to mean the tracking branch $foo/bar, which does not exist. Use:

  git remote set-default $foo <name>

to set a new default branch for $foo. """

(And, of course, add that subcommand to remote)
	-Daniel
*This .sig left intentionally blank*
Jeff King· Jan 21, 2009, 19:53 UTC · re: Daniel Barkalow · lore

Re: Deleting remote branch pointed by remote HEAD

On Wed, Jan 21, 2009 at 02:50:40PM -0500, Daniel Barkalow wrote:
Show 13 quoted lines
> I think the ideal thing is to keep the symref as a reminder and just give 
> a non-confusing error message instead of a confusing one. E.g.:
> 
> """
> $foo is set to mean the tracking branch $foo/bar, which does not exist. 
> Use:
> 
>   git remote set-default $foo <name>
> 
> to set a new default branch for $foo.
> """
> 
> (And, of course, add that subcommand to remote)

I think that would be reasonable behavior (and probably a special mode for set-default to just update from the remote's idea of HEAD).

-Peff
Felipe Contreras· Mar 12, 2009, 09:02 UTC · re: Jeff King · lore

Re: Deleting remote branch pointed by remote HEAD

On Wed, Jan 21, 2009 at 9:53 PM, Jeff King <peff@peff.net> wrote:
Show 18 quoted lines
> On Wed, Jan 21, 2009 at 02:50:40PM -0500, Daniel Barkalow wrote:
>
>> I think the ideal thing is to keep the symref as a reminder and just give
>> a non-confusing error message instead of a confusing one. E.g.:
>>
>> """
>> $foo is set to mean the tracking branch $foo/bar, which does not exist.
>> Use:
>>
>>   git remote set-default $foo <name>
>>
>> to set a new default branch for $foo.
>> """
>>
>> (And, of course, add that subcommand to remote)
>
> I think that would be reasonable behavior (and probably a special mode
> for set-default to just update from the remote's idea of HEAD).
Nobody is working on this, right?
-- 
Felipe Contreras
Jeff King· Mar 12, 2009, 11:39 UTC · re: Felipe Contreras · lore

Re: Deleting remote branch pointed by remote HEAD

On Thu, Mar 12, 2009 at 11:02:08AM +0200, Felipe Contreras wrote:
Show 6 quoted lines
> >>   git remote set-default $foo <name>
> [...]
> > I think that would be reasonable behavior (and probably a special mode
> > for set-default to just update from the remote's idea of HEAD).
> 
> Nobody is working on this, right?

Jay has a number of improvements to "git remote" in next, including this. See 104a914 (Merge branch 'js/remote-improvements' into next, 2009-03-05). Especially bc14fac (builtin-remote: add set-head subcommand, 2009-02-25).

-Peff
Felipe Contreras· Mar 12, 2009, 12:47 UTC · re: Jeff King · lore

Re: Deleting remote branch pointed by remote HEAD

On Thu, Mar 12, 2009 at 1:39 PM, Jeff King <peff@peff.net> wrote:
Show 13 quoted lines
> On Thu, Mar 12, 2009 at 11:02:08AM +0200, Felipe Contreras wrote:
>
>> >>   git remote set-default $foo <name>
>> [...]
>> > I think that would be reasonable behavior (and probably a special mode
>> > for set-default to just update from the remote's idea of HEAD).
>>
>> Nobody is working on this, right?
>
> Jay has a number of improvements to "git remote" in next, including
> this. See 104a914 (Merge branch 'js/remote-improvements' into next,
> 2009-03-05). Especially bc14fac (builtin-remote: add set-head
> subcommand, 2009-02-25).
Yes, I looked at that, but set-head will only change the remote HEAD locally.
-- 
Felipe Contreras
Jeff King· Mar 12, 2009, 12:50 UTC · re: Felipe Contreras · lore

Re: Deleting remote branch pointed by remote HEAD

On Thu, Mar 12, 2009 at 02:47:24PM +0200, Felipe Contreras wrote:
Show 16 quoted lines
> On Thu, Mar 12, 2009 at 1:39 PM, Jeff King <peff@peff.net> wrote:
> > On Thu, Mar 12, 2009 at 11:02:08AM +0200, Felipe Contreras wrote:
> >
> >> >>   git remote set-default $foo <name>
> >> [...]
> >> > I think that would be reasonable behavior (and probably a special mode
> >> > for set-default to just update from the remote's idea of HEAD).
> >>
> >> Nobody is working on this, right?
> >
> > Jay has a number of improvements to "git remote" in next, including
> > this. See 104a914 (Merge branch 'js/remote-improvements' into next,
> > 2009-03-05). Especially bc14fac (builtin-remote: add set-head
> > subcommand, 2009-02-25).
> 
> Yes, I looked at that, but set-head will only change the remote HEAD locally.

That was what the thread you were replying to was about. If you are proposing a command to set the HEAD in a remote repository, then no, I don't think anybody is working on that.

-Peff
Junio C Hamano· Jan 21, 2009, 20:42 UTC · re: Daniel Barkalow · lore

Re: Deleting remote branch pointed by remote HEAD

Daniel Barkalow <barkalow@iabervon.org> writes:
Show 8 quoted lines
> That is, refs/remotes/origin/HEAD is only there to let the user abbreviate 
> the most useful branch of the remote; there's no reason it should reflect 
> the remote's HEAD, except that the remote's HEAD is a good guess if the 
> user hasn't said anything.
>
> I think it might be more appropriate to just care less about a broken 
> symref, explain what's wrong if the user actually tries to use it, and 
> otherwise mostly ignore it.
I agree with you in many of the points in your message.

The user used to be able to say "origin" as a shorthand for "origin/frotz" by having "remotes/origin/HEAD" locally, and somebody (not necessarily the user himself) broke this arrangement. Silently discarding HEAD will lose the information on which remote branch was the interesting one for the user. It may also change the disambiguation rules for "origin" without telling the user. Neither is desirable.

The tool needs a better explanation of the situation. We also want an easier way to help the user repoint the HEAD to something else, or remove the dangling HEAD than telling him to use symbolic-ref.

Felipe Contreras· Jan 21, 2009, 18:31 UTC · re: Jeff King · lore

Re: Deleting remote branch pointed by remote HEAD

On Wed, Jan 21, 2009 at 6:19 PM, Jeff King <peff@peff.net> wrote:
Show 52 quoted lines
> On Wed, Jan 21, 2009 at 04:24:56PM +0100, Michael J Gruber wrote:
>
>> So, you get these errors on the local repo when dealing with the remote
>> repo, right? I guess this means two things:
>>
>> 1) You are deleting a remote branch
>
> Actually, he doesn't have to delete the remote branch; somebody else
> can. The problem is that the HEAD pointer for his remote tracking
> branches points to a branch that doesn't exist. This can happen because
> we sometimes update the tracking branches (including deletion) without
> impacting the HEAD pointer.
>
> There are two ways that I can think of (and there may be more) to
> provoke this:
>
>  1. delete a remote branch via push. The local side will helpfully
>     delete your local tracking branch to match what happened on the
>     remote. If it was the remote's HEAD, then you get a broken state
>     (and while we discourage pushing to the remote HEAD on a non-bare
>     repo, it is perfectly OK for a bare one).
>
>  2. somebody else deletes the remote branch that is the HEAD, and you
>     update your tracking branches via "git remote prune", which deletes
>     your tracking branches corresponding to any deleted remote branches.
>
> And actually there is a slight variant on both of the above. The deleted
> branch does not actually have to be the current HEAD on the remote. It
> just has to match your _idea_ of the current HEAD on the remote, which
> may be out of date.
>
> Situation (1) happens entirely locally. So it can be fixed fairly easily
> by checking whether the remote tracking HEAD points to a branch we are
> deleting, and deleting the HEAD in that case (the code should be in
> builtin-send-pack.c:update_tracking_ref). Of course you have probably
> also created a broken situation on the remote, so perhaps receive-pack
> should handle that.
>
> Situation (2) could do something similar: when we see that we are about
> to delete the ref pointed to by the remote tracking HEAD, we could
> delete the HEAD.
>
> But both situations are a little hack-ish to me. You are deleting the
> HEAD because you don't know what the right value is from the remote end.
> A better fix would be to actually pull the HEAD information down during
> fetch. And I seem to recall a patch about that at some point (it
> required a new protocol extension), but I don't know what become of it.
>
> However, even if we kept the tracking HEAD totally in sync with the
> remote's HEAD, it still may be possible that the remote HEAD is broken.
> In which case it might be nice to detect that when pulling it down and
> just leave the tracking HEAD unset.

Why should we care about the remote HEAD? Isn't that relevant only when cloning to find out the branch to checkout?

Also, it's not nice to leave the remote repo with a broken HEAD pointer, shouldn't git ask for a new head, or fail with a proper message?

-- 
Felipe Contreras
Jeff King· Jan 21, 2009, 19:16 UTC · re: Felipe Contreras · lore

Re: Deleting remote branch pointed by remote HEAD

On Wed, Jan 21, 2009 at 08:31:50PM +0200, Felipe Contreras wrote:
> Why should we care about the remote HEAD? Isn't that relevant only
> when cloning to find out the branch to checkout?

You can use the shorthand $foo to refer to refs/remotes/$foo/HEAD. Which means, in the default case, you can refer to just "origin" to talk about origin's master branch.

But as Daniel noted, that is really about local preference for "what is the most interesting branch on the remote". You might want to track what the remote sets to HEAD, or you might want to set it individually.

-Peff
Felipe Contreras· Jan 21, 2009, 19:20 UTC · re: Jeff King · lore

Re: Deleting remote branch pointed by remote HEAD

On Wed, Jan 21, 2009 at 9:16 PM, Jeff King <peff@peff.net> wrote:
Show 12 quoted lines
> On Wed, Jan 21, 2009 at 08:31:50PM +0200, Felipe Contreras wrote:
>
>> Why should we care about the remote HEAD? Isn't that relevant only
>> when cloning to find out the branch to checkout?
>
> You can use the shorthand $foo to refer to refs/remotes/$foo/HEAD. Which
> means, in the default case, you can refer to just "origin" to talk about
> origin's master branch.
>
> But as Daniel noted, that is really about local preference for "what is
> the most interesting branch on the remote". You might want to track what
> the remote sets to HEAD, or you might want to set it individually.

Ah, good to know. But then the message should appear only when doing something with the $foo branch.

-- 
Felipe Contreras
Adeodato Simó· Jan 21, 2009, 14:41 UTC · re: Michael J Gruber · lore

Re: Deleting remote branch pointed by remote HEAD

* Michael J Gruber [Wed, 21 Jan 2009 15:33:36 +0100]:
> Marc-André Lureau venit, vidit, dixit 21.01.2009 14:02:
> > Hi
> > I deleted a remote branch which was pointed by HEAD, this way: "git
> > push origin :master"
> > Then for almost every git command, I get this error: "error:
> > refs/remotes/origin/HEAD points nowhere!".
> You're talking about about the remote git repo, aren't you?
> > I found this situation non-friendly. Fortunately, I could understand
> > what's going on. But a new user might be confused.
> > Shouldn't the remote HEAD branch be updated or "protected" in some
> > ways? Or should the "error" be considered as a "warning" (silently?)
> > What do you think?
Show 9 quoted lines
> I think that git said
> "warning: updating the currently checked out branch; this may cause
> confusion,
> as the index and working tree do not reflect changes that are now in HEAD."
> after your push and that this may have rung some bells. I also think
> that pushing to a non-bare remote repo (one with a worktree checked out)
> is strongly advised against in multiple places, unless you know what
> you're doing - which you seem to do since you were able to restore your
> HEAD ;)

I don't think Marc-André was pushing to a non-bare repo, but it doesn't really matter, because his issue also shows up with bare repos: if you delete the branch to which HEAD points in a remote repo, you get no warning, and then cloning that bare repo does not fully work, because its HEAD points to a non-existent ref.

    % g clone ssh://.../foo.git
    % cd foo
    % g push origin :master
    % cd ..
    % g clone ssh://.../foo.git foo2
    ...
    warning: remote HEAD refers to nonexistent ref, unable to checkout.

What would git usefully do in this situation, I don't know. But I thought I'd clear up the above confusion.

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
Truth is the most valuable thing we have, so let's economize it.
                -- Mark Twain
Sitaram Chamarty· Jan 21, 2009, 14:52 UTC · re: Marc-André Lureau · lore

Re: Deleting remote branch pointed by remote HEAD

On 2009-01-21, Marc-André Lureau <marcandre.lureau@gmail.com> wrote:
Show 8 quoted lines
> I deleted a remote branch which was pointed by HEAD, this way: "git
> push origin :master"
>
> Then for almost every git command, I get this error: "error:
> refs/remotes/origin/HEAD points nowhere!".
>
> I found this situation non-friendly. Fortunately, I could understand
> what's going on. But a new user might be confused.

That's a pretty advanced command for a beginner. I have people who're only using the GUI (in the presumption that it will be less confusing or less powerful or whatever) and have managed to right click on a remote branch, choose "checkout this branch" and have made commits on it without knowing they're not on any branch!

I wish I had your problem :-)
Daniel Barkalow· Jan 21, 2009, 22:56 UTC · re: Sitaram Chamarty · lore

GUI and detatched HEAD (was Re: Deleting remote branch pointed by remote HEAD)

On Wed, 21 Jan 2009, Sitaram Chamarty wrote:
Show 17 quoted lines
> On 2009-01-21, Marc-André Lureau <marcandre.lureau@gmail.com> wrote:
> 
> > I deleted a remote branch which was pointed by HEAD, this way: "git
> > push origin :master"
> >
> > Then for almost every git command, I get this error: "error:
> > refs/remotes/origin/HEAD points nowhere!".
> >
> > I found this situation non-friendly. Fortunately, I could understand
> > what's going on. But a new user might be confused.
> 
> That's a pretty advanced command for a beginner.  I have
> people who're only using the GUI (in the presumption that it
> will be less confusing or less powerful or whatever) and
> have managed to right click on a remote branch, choose
> "checkout this branch" and have made commits on it without
> knowing they're not on any branch!

I wonder if the GUI could handle this in a way that users would understand. This is qualitively like following a link to a spreadsheet in your web browser, having the browser launch your office suite and load the spreadsheet off the web; now you're interacting with a spreadsheet where you obviously can't save to the original location (which is some web site) and haven't provided a local filename to save as.

I think the right thing would be to show it as "(Untitled)" and have a prominant button to make a real saved branch out of it. There's nothing all that strange about having a current "document" that has no filename yet; the strange thing is that a version control system has this capability.

	-Daniel
*This .sig left intentionally blank*
Sitaram Chamarty· Jan 22, 2009, 14:20 UTC · re: Daniel Barkalow · lore

Re: GUI and detatched HEAD (was Re: Deleting remote branch pointed by remote HEAD)

On 2009-01-21, Daniel Barkalow <barkalow@iabervon.org> wrote:
Show 7 quoted lines
> On Wed, 21 Jan 2009, Sitaram Chamarty wrote:
>> have managed to right click on a remote branch, choose
>> "checkout this branch" and have made commits on it without
>> knowing they're not on any branch!
>
> I wonder if the GUI could handle this in a way that users would 
> understand. This is qualitively like following a link to a spreadsheet in

I'd be happy with a simple warning message saying "are you sure you know what you are doing?" or words to that effect :-)

← back to recent threads