Deleting remote branch pointed by remote HEAD

Deleting remote branch pointed by remote HEAD

[Marc-André Lureau]

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

Re: Deleting remote branch pointed by remote HEAD

[Michael J Gruber]

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?

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

Re: Deleting remote branch pointed by remote HEAD

[Marc-André Lureau]

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.

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

> 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

Re: Deleting remote branch pointed by remote HEAD

[Adeodato Simó]

* 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?

> 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

Re: Deleting remote branch pointed by remote HEAD

[Sitaram Chamarty]

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 wish I had your problem :-)

Re: Deleting remote branch pointed by remote HEAD

[Michael J Gruber]

Marc-André Lureau venit, vidit, dixit 21.01.2009 15:38:
> 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

Re: Deleting remote branch pointed by remote HEAD

[Marc-André Lureau]

Hi

On Wed, Jan 21, 2009 at 5:24 PM, Michael J Gruber
<git@drmicha.warpmail.net> 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
>
> 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)

> 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

Re: Deleting remote branch pointed by remote HEAD

[Jeff King]

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

Re: Deleting remote branch pointed by remote HEAD

[Daniel Barkalow]

On Wed, 21 Jan 2009, Jeff King wrote:

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

Re: Deleting remote branch pointed by remote HEAD

[Felipe Contreras]

On Wed, Jan 21, 2009 at 6:19 PM, Jeff King <peff@peff.net> wrote:
> 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

Re: Deleting remote branch pointed by remote HEAD

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]

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/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Deleting remote branch pointed by remote HEAD

[Jeff King]

On Wed, Jan 21, 2009 at 01:30:10PM -0500, Daniel Barkalow wrote:

> 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

Re: Deleting remote branch pointed by remote HEAD

[Jeff King]

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.

-Peff

Re: Deleting remote branch pointed by remote HEAD

[Jeff King]

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

Re: Deleting remote branch pointed by remote HEAD

[Felipe Contreras]

On Wed, Jan 21, 2009 at 9:16 PM, Jeff King <peff@peff.net> wrote:
> 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

Re: Deleting remote branch pointed by remote HEAD

[Daniel Barkalow]

On Wed, 21 Jan 2009, Jeff King wrote:

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

Re: Deleting remote branch pointed by remote HEAD

[Jeff King]

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

-Peff

Re: Deleting remote branch pointed by remote HEAD

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

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

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

[Daniel Barkalow]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1564 bytes --]

On Wed, 21 Jan 2009, Sitaram Chamarty wrote:

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

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

[Sitaram Chamarty]

On 2009-01-21, Daniel Barkalow <barkalow@iabervon.org> wrote:
> 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
:-)

Re: Deleting remote branch pointed by remote HEAD

[Felipe Contreras]

On Wed, Jan 21, 2009 at 9:53 PM, Jeff King <peff@peff.net> wrote:
> 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

Re: Deleting remote branch pointed by remote HEAD

[Jeff King]

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

-Peff

Re: Deleting remote branch pointed by remote HEAD

[Felipe Contreras]

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.

-- 
Felipe Contreras

Re: Deleting remote branch pointed by remote HEAD

[Jeff King]

On Thu, Mar 12, 2009 at 02:47:24PM +0200, Felipe Contreras wrote:

> 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