{"thread":{"id":"6597","subject":"[PATCH] tone down the detached head warning","startedAt":"2007-01-31T19:10:37Z","lastAt":"2007-02-02T02:38:51Z","messageCount":35,"participants":["Nicolas Pitre","Jeff King","Jakub Narebski","Carl Worth","Junio C Hamano","Andy Parkins","Raimund Bauer","Alex Riesen","Matthias Lederhofer","Theodore Tso"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"33166","messageId":"Pine.LNX.4.64.0701311405430.3021@xanadu.home","threadId":"6597","inReplyTo":null,"subject":"[PATCH] tone down the detached head warning","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-01-31T19:10:37Z","receivedAt":"2007-01-31T19:10:37Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"This is not meant to frighten people or even to suggest they might be\ndoing something wrong, but rather to notify them of a state change and\nprovide a likely option in the case this state was entered by mistake.\n\nSigned-off-by: Nicolas Pitre <nico@cam.org>\n\n---\n\ndiff --git a/git-checkout.sh b/git-checkout.sh\nindex 8500f51..0bae86e 100755\n--- a/git-checkout.sh\n+++ b/git-checkout.sh\n@@ -155,9 +155,9 @@ then\n \tdetached=\"$new\"\n \tif test -n \"$oldbranch\"\n \tthen\n-\t\tdetach_warn=\"warning: you are not on ANY branch anymore.\n-If you meant to create a new branch from this checkout, you may still do\n-so (now or later) by using -b with the checkout command again.  Example:\n+\t\tdetach_warn=\"Note: you are not on ANY branch anymore.\n+If you want to create a new branch from this checkout, you may do so\n+(now or later) by using -b with the checkout command again. Example:\n   git checkout -b <new_branch_name>\"\n \tfi\n elif test -z \"$oldbranch\" && test -n \"$branch\"\n"},{"id":"33186","messageId":"20070131231942.GB31145@coredump.intra.peff.net","threadId":"6597","inReplyTo":"Pine.LNX.4.64.0701311405430.3021@xanadu.home","subject":"Re: [PATCH] tone down the detached head warning","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-01-31T23:19:43Z","receivedAt":"2007-01-31T23:19:43Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 31, 2007 at 02:10:37PM -0500, Nicolas Pitre wrote:\n\n> This is not meant to frighten people or even to suggest they might be\n> doing something wrong, but rather to notify them of a state change and\n> provide a likely option in the case this state was entered by mistake.\n\nI like this much better. Though I wonder in Carl's case if we can do\neven better, since the user is checking out a tracking branch. Does it\nreally make sense to say \"you are not on ANY branch\"? Maybe instead:\n\n-- >8 --\ngit-checkout: note use of remote tracking branch when making detached warning\n\n---\nCarl, can you comment? Does this require more explanation about why it\nmatters that you're on a remote tracking branch?\n\n git-checkout.sh |   10 +++++++++-\n 1 files changed, 9 insertions(+), 1 deletions(-)\n\ndiff --git a/git-checkout.sh b/git-checkout.sh\nindex ed04815..68533a1 100755\n--- a/git-checkout.sh\n+++ b/git-checkout.sh\n@@ -14,6 +14,7 @@ force=\n branch=\n newbranch=\n newbranch_log=\n+detached_remote=\n merge=\n LF='\n '\n@@ -58,6 +59,9 @@ while [ \"$#\" != \"0\" ]; do\n \t\t\tif git-show-ref --verify --quiet -- \"refs/heads/$arg\"\n \t\t\tthen\n \t\t\t\tbranch=\"$arg\"\n+\t\t\telif git-show-ref --verify --quiet -- \"refs/remotes/$arg\"\n+\t\t\tthen\n+\t\t\t\tdetached_remote=\"$arg\"\n \t\t\tfi\n \t\telif rev=$(git-rev-parse --verify \"$arg^{tree}\" 2>/dev/null)\n \t\tthen\n@@ -155,7 +159,11 @@ then\n \tdetached=\"$new\"\n \tif test -n \"$oldbranch\"\n \tthen\n-\t\tdetach_warn=\"Note: you are not on ANY branch anymore.\n+\t\tcase \"$detached_remote\" in\n+\t\t  \"\") detach_warn=\"Note: you are not on ANY branch anymore.\" ;;\n+\t\t   *) detach_warn=\"Note: you are on the remote tracking branch '$detached_remote'\" ;;\n+\t\tesac\n+\t\tdetach_warn=\"$detach_warn\n If you want to create a new branch from this checkout, you may do so\n (now or later) by using -b with the checkout command again. Example:\n   git checkout -b <new_branch_name>\"\n-- \n1.5.0.rc2.587.gbedb-dirty\n"},{"id":"33187","messageId":"epr8e9$i7r$1@sea.gmane.org","threadId":"6597","inReplyTo":"20070131231942.GB31145@coredump.intra.peff.net","subject":"Re: [PATCH] tone down the detached head warning","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-31T23:25:14Z","receivedAt":"2007-01-31T23:25:14Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King wrote:\n\n> On Wed, Jan 31, 2007 at 02:10:37PM -0500, Nicolas Pitre wrote:\n> \n>> This is not meant to frighten people or even to suggest they might be\n>> doing something wrong, but rather to notify them of a state change and\n>> provide a likely option in the case this state was entered by mistake.\n> \n> I like this much better. Though I wonder in Carl's case if we can do\n> even better, since the user is checking out a tracking branch. Does it\n> really make sense to say \"you are not on ANY branch\"? Maybe instead:\n> \n> -- >8 --\n> git-checkout: note use of remote tracking branch when making detached warning\n \nYou can checkout a tag, not a remote tracking branch!\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"33188","messageId":"20070131232748.GC31145@coredump.intra.peff.net","threadId":"6597","inReplyTo":"epr8e9$i7r$1@sea.gmane.org","subject":"Re: [PATCH] tone down the detached head warning","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-01-31T23:27:48Z","receivedAt":"2007-01-31T23:27:48Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 01, 2007 at 12:25:14AM +0100, Jakub Narebski wrote:\n\n> > git-checkout: note use of remote tracking branch when making detached warning\n> You can checkout a tag, not a remote tracking branch!\n\nHuh?\n\n$ git-checkout master\n$ git-checkout origin/pu\nNote: you are on the remote tracking branch 'origin/pu'\nIf you want to create a new branch from this checkout, you may do so\n(now or later) by using -b with the checkout command again. Example:\n  git checkout -b <new_branch_name>\n$ git-checkout master\n$ git-checkout v1.4.4.4\nNote: you are not on ANY branch anymore.\nIf you want to create a new branch from this checkout, you may do so\n(now or later) by using -b with the checkout command again. Example:\n  git checkout -b <new_branch_name>\n\nYou _can_ check out a tracking branch (in fact, I believe that is what\nCarl was proposing for his users to do, but perhaps he had instead\nactually tagged it). And my patch leaves the traditional output for a\ntag (since you, are in fact, not on any branch at that point).\n\n-Peff\n"},{"id":"33189","messageId":"epr8u0$i7r$2@sea.gmane.org","threadId":"6597","inReplyTo":"20070131232748.GC31145@coredump.intra.peff.net","subject":"Re: [PATCH] tone down the detached head warning","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-31T23:33:38Z","receivedAt":"2007-01-31T23:33:38Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King wrote:\n\n> On Thu, Feb 01, 2007 at 12:25:14AM +0100, Jakub Narebski wrote:\n> \n>>> git-checkout: note use of remote tracking branch when making detached warning\n>>\n>> You can checkout a tag, not a remote tracking branch!\n> \n> Huh?\n\nOoops, I meant not _only_ a remote tracking branch (so note about detached\nHEAD shouldn't talk about remote tracking branch unless we make sure that\nit is remote tracking branch). Sorry.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"33191","messageId":"87wt32ah2e.wl%cworth@cworth.org","threadId":"6597","inReplyTo":"20070131231942.GB31145@coredump.intra.peff.net","subject":"Re: [PATCH] tone down the detached head warning","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-01-31T23:54:01Z","receivedAt":"2007-01-31T23:54:01Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 31 Jan 2007 18:19:43 -0500, Jeff King wrote:\n> I like this much better. Though I wonder in Carl's case if we can do\n> even better, since the user is checking out a tracking branch. Does it\n> really make sense to say \"you are not on ANY branch\"? Maybe instead:\n...\n> Carl, can you comment? Does this require more explanation about why it\n> matters that you're on a remote tracking branch?\n\nGetting rid of the word \"Warning\" and naming the remote-tracking\nbranch instead of saying \"not on ANY branch\", (my, why should git ever\nyell like that?), are definitely improvements.\n\nBut they're fairly incremental. The fact is that the user is doing a\nvery simple operation here, (just checking out a state for which git\nalready has a name), and the user is given 3 lines of text to read and\ntry to understand, (what the heck is a \"remote tracking branch\"\nanyway?). It still looks to me like the kind of thing that promotes a\n\"git is hard to use\" conception.\n\nBut, back to the original use case that brought this up. I did botch\nsomething in the original description. The \"git clone; git checkout\norigin/branch-name\" case does trigger the detached head state with its\nwarnings. But the other alternative I showed does not:\n\n\tgit fetch git://... branch-name:branch-name\n\nHere, of course the user can use:\n\n\tgit checkout branch-name\n\nand not ever enter the \"detached HEAD\" state at all. So with this\nusage the discussion about where and when to warn becomes moot.\n\nBut this still isn't satisfying to me as something to offer users, as\nI'd really like them to be able to just \"git pull\" to follow\nsubsequent things I commit to the branch. But for that the user would\nstill need a bunch of configuration setup.\n\nSo it does come around to the fact that I'd like it to be easier for a\nuser to get all the configuration setup for a local branch that knows\nwhich remote-tracking branch its associated with, (and this whether or\nnot the remote-tracking branch was configured as part of the original\nclone or not).\n\n-Carl\n"},{"id":"33193","messageId":"Pine.LNX.4.64.0701311907500.3021@xanadu.home","threadId":"6597","inReplyTo":"20070131231942.GB31145@coredump.intra.peff.net","subject":"Re: [PATCH] tone down the detached head warning","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-01T00:11:34Z","receivedAt":"2007-02-01T00:11:34Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 31 Jan 2007, Jeff King wrote:\n\n> On Wed, Jan 31, 2007 at 02:10:37PM -0500, Nicolas Pitre wrote:\n> \n> > This is not meant to frighten people or even to suggest they might be\n> > doing something wrong, but rather to notify them of a state change and\n> > provide a likely option in the case this state was entered by mistake.\n> \n> I like this much better. Though I wonder in Carl's case if we can do\n> even better, since the user is checking out a tracking branch. Does it\n> really make sense to say \"you are not on ANY branch\"? Maybe instead:\n> \n[...]\n> +\t\tcase \"$detached_remote\" in\n> +\t\t  \"\") detach_warn=\"Note: you are not on ANY branch anymore.\" ;;\n> +\t\t   *) detach_warn=\"Note: you are on the remote tracking branch '$detached_remote'\" ;;\n> +\t\tesac\n\nNo.  This is misleading.\n\nYou are _not_ on the remote tracking branch.  You just happen to have \nchecked out a commit that came from a tracking branch, but you are still \ndetached from any branch at that point.\n\n\nNicolas\n"},{"id":"33194","messageId":"eprbaa$o0m$1@sea.gmane.org","threadId":"6597","inReplyTo":"87wt32ah2e.wl%cworth@cworth.org","subject":"Re: [PATCH] tone down the detached head warning","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-01T00:14:20Z","receivedAt":"2007-02-01T00:14:20Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Carl Worth wrote:\n\n> So it does come around to the fact that I'd like it to be easier for a\n> user to get all the configuration setup for a local branch that knows\n> which remote-tracking branch its associated with, (and this whether or\n> not the remote-tracking branch was configured as part of the original\n> clone or not).\n \nThere is new (untested and not complete) command git-remote for that.\n\nAlthough the fact that clone copies all branches and tags (I don't think\nthere is a way to clone only subset of branches), and that fetch is multi\nbranch might be deterrent enough (unless one use one branch per repo).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"33201","messageId":"20070201030030.GA1979@coredump.intra.peff.net","threadId":"6597","inReplyTo":"Pine.LNX.4.64.0701311907500.3021@xanadu.home","subject":"Re: [PATCH] tone down the detached head warning","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-02-01T03:00:30Z","receivedAt":"2007-02-01T03:00:30Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 31, 2007 at 07:11:34PM -0500, Nicolas Pitre wrote:\n\n> No.  This is misleading.\n> \n> You are _not_ on the remote tracking branch.  You just happen to have \n> checked out a commit that came from a tracking branch, but you are still \n> detached from any branch at that point.\n\nSure, but that is a very subtle distinction that I doubt will make sense\nto git newbies. Having them check out what they consider to be a branch\n(and which is, in fact, a line of development -- just not one that you\nhave locally marked as a head) and responding with \"you are not on ANY\nbranch\" is a little off-putting.\n\nIs there some text we can use that makes more sense in all situations?\n\nI think part of the \"scariness\" of the message is that git-checkout does\nnot _usually_ produce output. I wonder if, when switching HEAD, it\nusually printed \"Now on branch <foo>\", and for detached printed some\nspecial variant, it would seem more natural.\n\n-Peff\n"},{"id":"33204","messageId":"7vd54ur26u.fsf@assigned-by-dhcp.cox.net","threadId":"6597","inReplyTo":"20070201030030.GA1979@coredump.intra.peff.net","subject":"Re: [PATCH] tone down the detached head warning","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-01T03:23:21Z","receivedAt":"2007-02-01T03:23:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I think part of the \"scariness\" of the message is that git-checkout does\n> not _usually_ produce output. I wonder if, when switching HEAD, it\n> usually printed \"Now on branch <foo>\", and for detached printed some\n> special variant, it would seem more natural.\n\nThat sounds sensible.  Another thing I found slightly annoying\nabout branch switching in git-checkout is that we list the paths\nwith local changes only when the tip of the old branch and the\nnew branch are different.  Very often I start hacking while on\n'master' and later find the change forms a concrete \"theme\", and\nthen say \"git checkout -b that-theme\" to switch a branch; in\nsuch a case I do want the list of locally modified paths.\n\nFor example:\n\n\t: gitster project/master; edit foo.c\n        : gitster project/master; git checkout -b theme\n\tM\tfoo.c\n\tSwitched to a new branch \"theme\"\n\t: gitster project/theme; edit bar.c\n        : gitster project/theme; git checkout master\n\tM\tbar.c\n        M\tfoo.c\n        Switched to branch \"master\"\n\t: gitster project/master; git checkout master^\n\tM\tbar.c\n        M\tfoo.c\n\tDetached your HEAD -- you are not on any branch.\n        If you want to create a new branch from this checkout, you may do so\n        (now or later) by using -b with the checkout command again. Example:\n          git checkout -b <new_branch_name>\n\t: gitster project; \n\nwould feel very natural and much less scary.\n\nNote.  I run with PS1=': \\h \\W$(__git_ps1 \"/%s\"); '.\n"},{"id":"33205","messageId":"20070201032925.GA2505@coredump.intra.peff.net","threadId":"6597","inReplyTo":"7vd54ur26u.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] tone down the detached head warning","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-02-01T03:29:25Z","receivedAt":"2007-02-01T03:29:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 31, 2007 at 07:23:21PM -0800, Junio C Hamano wrote:\n\n>         M\tfoo.c\n>         Switched to branch \"master\"\n> \t: gitster project/master; git checkout master^\n> \tM\tbar.c\n>         M\tfoo.c\n> \tDetached your HEAD -- you are not on any branch.\n>         If you want to create a new branch from this checkout, you may do so\n>         (now or later) by using -b with the checkout command again. Example:\n>           git checkout -b <new_branch_name>\n> \t: gitster project; \n>\n> would feel very natural and much less scary.\n\n\nMuch improved, IMHO. As an added bonus, I think it creates some feedback\nthat lets a user know when they have mistakenly used 'git checkout' to\nswitch heads when they meant to restore a file.\n\nI still wish there was some other language for detaching to a commit\nspecified by a remote tracking branch; it just seems wrong to say \"you\nare not on any branch\" right after the user requests to checkout a\nbranch (admittedly not one of their local branches, but for a user\nmerely poking through the repository, the difference is probably not\nimportant).\n\n-Peff\n"},{"id":"33206","messageId":"Pine.LNX.4.64.0701312238420.3021@xanadu.home","threadId":"6597","inReplyTo":"20070201032925.GA2505@coredump.intra.peff.net","subject":"Re: [PATCH] tone down the detached head warning","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-01T03:47:31Z","receivedAt":"2007-02-01T03:47:31Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 31 Jan 2007, Jeff King wrote:\n\n> On Wed, Jan 31, 2007 at 07:23:21PM -0800, Junio C Hamano wrote:\n> \n> >         M\tfoo.c\n> >         Switched to branch \"master\"\n> > \t: gitster project/master; git checkout master^\n> > \tM\tbar.c\n> >         M\tfoo.c\n> > \tDetached your HEAD -- you are not on any branch.\n> >         If you want to create a new branch from this checkout, you may do so\n> >         (now or later) by using -b with the checkout command again. Example:\n> >           git checkout -b <new_branch_name>\n> > \t: gitster project; \n> >\n> > would feel very natural and much less scary.\n> \n> \n> Much improved, IMHO. As an added bonus, I think it creates some feedback\n> that lets a user know when they have mistakenly used 'git checkout' to\n> switch heads when they meant to restore a file.\n\nIndeed.\n\n> I still wish there was some other language for detaching to a commit\n> specified by a remote tracking branch; it just seems wrong to say \"you\n> are not on any branch\" right after the user requests to checkout a\n> branch (admittedly not one of their local branches, but for a user\n> merely poking through the repository, the difference is probably not\n> important).\n\nBut this language convey the truth and users will have to get used to it \nat some point. We should not hide the fact that HEAD is really detached at\nthat point, otherwise it could be presumed that a commit might update the\nchecked out (tracking) branch which is obviously not the case.\n\n\nNicolas\n"},{"id":"33207","messageId":"20070201035450.GA2862@coredump.intra.peff.net","threadId":"6597","inReplyTo":"Pine.LNX.4.64.0701312238420.3021@xanadu.home","subject":"Re: [PATCH] tone down the detached head warning","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-02-01T03:54:50Z","receivedAt":"2007-02-01T03:54:50Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 31, 2007 at 10:47:31PM -0500, Nicolas Pitre wrote:\n\n> But this language convey the truth and users will have to get used to it \n> at some point. We should not hide the fact that HEAD is really detached at\n> that point, otherwise it could be presumed that a commit might update the\n> checked out (tracking) branch which is obviously not the case.\n\nOK, so let's not lie about it, then. But that doesn't mean we can't\nexplain further. What about:\n\n$ git checkout origin/pu\nDetached your HEAD (based on remote origin/pu) -- you are not on any branch\n...\n\nExcept that I think the line is getting a bit long. But the point is to\nexplain _why_ we're detached (you could even put a different note for\ntags). If a user already knows that 'git checkout v1.4.4.4' is going to\nput him in a detached state, then he doesn't really care about the\nmessage one way or the other. But if he doesn't know (and there is no\nclue on the command line, except for the fact that we already know\nv1.4.4.4 is a tag and origin/pu is a remote tracking branch), then it\nmight make it more why it happened.\n\n-Peff\n"},{"id":"33213","messageId":"200702010844.34500.andyparkins@gmail.com","threadId":"6597","inReplyTo":"eprbaa$o0m$1@sea.gmane.org","subject":"Re: [PATCH] tone down the detached head warning","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-01T08:44:32Z","receivedAt":"2007-02-01T08:44:32Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007 February 01 00:14, Jakub Narebski wrote:\n\n> Although the fact that clone copies all branches and tags (I don't think\n> there is a way to clone only subset of branches), and that fetch is multi\n\nThere is, as long as you are willing to organise your branches in a consistent \nway.  I keep all my branches with the prefix \"ap/\" then on another \ndevelopment machine I just have\n\n pull = refs/heads/ap/*:refs/heads/up/ap/*\n\nIn my config.  This means I can make local branches that won't be grabbed \nduring the fetch, but still have branches automatically exported.\n\nThis actually highlights a weakness in the globbing.  There is no way, for \nexample, to grab only unprefixed branches because the glob is blind to path \ndividers (as is usual).  What would be even better would be a two glob \nsymbols, one meaning \"do cross separators\", one meaning \"don't\".  I think \nrsync solves it for it's include/exclude patterns with a double asterisk.  \nThat is:\n\n rsync -av --exclude \"foo/*/bar\" src/ dest/\n\nWould exclude anything called \"bar\" two levels under \"foo/\"; wheras\n\n rsync -av --exclude \"foo/**/bar\" src/ dest/\n\nWould exclude anything called \"bar\" anywhere deeper than two levels \nunder \"foo\".\n\nI haven't thought of a good way of applying this in git though, and I have a \nfeeling that it could just complicate things excessively.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"33215","messageId":"7vlkjip7mu.fsf_-_@assigned-by-dhcp.cox.net","threadId":"6597","inReplyTo":"7vd54ur26u.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] detached HEAD -- finishing touches","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-01T09:08:41Z","receivedAt":"2007-02-01T09:08:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This updates \"git-checkout\" to report which branch you are\nswitching to.  Especially for people who do not use __git_ps1\nfrom contrib/completion/git-completion.bash this would give a\nfriendlier feedback of what is going on, and should make the\nreminder message much less scary.\n\nHere is a sample session (the prompt tells which branch I am on).\n\n* I have some local modification and realize that the change deserves\n  to be on its own new topic branch.\n\n    [git.git (master)]$ git diff --stat\n     git-checkout.sh |   10 ++++++++--\n     1 files changed, 8 insertions(+), 2 deletions(-)\n\n* So I switch to a new branch.  I get a listing of local modifications\n  and assuring \"Switched to a new branch\" message.\n\n    [git.git (master)]$ git checkout -b jc/checkout\n    M       git-checkout.sh\n    Switched to a new branch \"jc/checkout\"\n\n* If I switch back to \"master\", I get essentially the same.\n\n    [git.git (jc/checkout)]$ git checkout master\n    M       git-checkout.sh\n    Switched to branch \"master\"\n\n* Detaching head would say which commit I am at and reminds me that\n  I am not on any branch (not that I would detach my HEAD while keeping\n  precious local changes around in any real-world workflow -- this is\n  just a sample session).\n\n    [git.git (master)]$ git checkout master^\n    M       git-checkout.sh\n    Note: you are not on any branch and are at commit \"master^\"\n    If you want to create a new branch from this checkout, you may do so\n    (now or later) by using -b with the checkout command again. Example:\n      git checkout -b <new_branch_name>\n\n* Coming back to an attached state can lose the detached HEAD, so\n  I get warned and stopped.\n\n    [git.git]$ git checkout master\n    You are not on any branch and switching to branch 'master'\n    may lose your changes.  At this point, you can do one of two things:\n     (1) Decide it is Ok and say 'git checkout -f master';\n     (2) Start a new branch from the current commit, by saying\n         'git checkout -b <branch-name>'.\n    Leaving your HEAD detached; not switching to branch 'master'.\n\n* Moving around while my HEAD is detached is Ok.  I still get the list\n  of local modifications.\n\n    [git.git]$ git checkout master^0\n    M       git-checkout.sh\n\n* The previous step that switched to the tip commit is an obscure but\n  useful trick.  My HEAD is still detached but now it is pointed at by\n  an existing ref, so I can come back safely.\n\n    [git.git]$ git checkout master\n    M       git-checkout.sh\n    Switched to branch \"master\"\n\n* And we are back on the \"master\" branch.\n\n    [git.git (master)]$ exit\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\nJunio C Hamano <junkio@cox.net> writes:\n\n> That sounds sensible.  Another thing I found slightly annoying\n> about branch switching in git-checkout is that we list the paths\n> with local changes only when the tip of the old branch and the\n> new branch are different.  Very often I start hacking while on\n> 'master' and later find the change forms a concrete \"theme\", and\n> then say \"git checkout -b that-theme\" to switch a branch; in\n> such a case I do want the list of locally modified paths.\n\n git-checkout.sh |   10 ++++++++--\n 1 files changed, 8 insertions(+), 2 deletions(-)\n\ndiff --git a/git-checkout.sh b/git-checkout.sh\nindex 0bae86e..deb4795 100755\n--- a/git-checkout.sh\n+++ b/git-checkout.sh\n@@ -155,7 +155,7 @@ then\n \tdetached=\"$new\"\n \tif test -n \"$oldbranch\"\n \tthen\n-\t\tdetach_warn=\"Note: you are not on ANY branch anymore.\n+\t\tdetach_warn=\"Note: you are not on any branch and are at commit \\\"$new_name\\\"\n If you want to create a new branch from this checkout, you may do so\n (now or later) by using -b with the checkout command again. Example:\n   git checkout -b <new_branch_name>\"\n@@ -228,7 +228,7 @@ else\n     saved_err=$?\n     if test \"$saved_err\" = 0\n     then\n-\ttest \"$new\" = \"$old\" || git diff-index --name-status \"$new\"\n+\tgit diff-index --name-status \"$new\"\n     fi\n     (exit $saved_err)\n fi\n@@ -251,6 +251,12 @@ if [ \"$?\" -eq 0 ]; then\n \tif test -n \"$branch\"\n \tthen\n \t\tGIT_DIR=\"$GIT_DIR\" git-symbolic-ref HEAD \"refs/heads/$branch\"\n+\t\tif test -n \"$newbranch\"\n+\t\tthen\n+\t\t\techo >&2 \"Switched to a new branch \\\"$branch\\\"\"\n+\t\telse\n+\t\t\techo >&2 \"Switched to branch \\\"$branch\\\"\"\n+\t\tfi\n \telif test -n \"$detached\"\n \tthen\n \t\t# NEEDSWORK: we would want a command to detach the HEAD\n"},{"id":"33217","messageId":"001a01c745e5$d59fde80$0b0aa8c0@abf.local","threadId":"6597","inReplyTo":"7vlkjip7mu.fsf_-_@assigned-by-dhcp.cox.net","subject":"RE: [PATCH] detached HEAD -- finishing touches","fromName":"Raimund Bauer","fromEmail":"ray007@gmx.net","sentAt":"2007-02-01T09:46:22Z","receivedAt":"2007-02-01T09:46:22Z","isPatch":true,"sender":{"key":"ray007@gmx.net","avatar":null},"body":">     [git.git (master)]$ git checkout master^\n>     M       git-checkout.sh\n>     Note: you are not on any branch and are at commit \"master^\"\n>     If you want to create a new branch from this checkout, \n> you may do so\n>     (now or later) by using -b with the checkout command \n> again. Example:\n>       git checkout -b <new_branch_name>\n> \n> * Coming back to an attached state can lose the detached HEAD, so\n>   I get warned and stopped.\n> \n>     [git.git]$ git checkout master\n>     You are not on any branch and switching to branch 'master'\n>     may lose your changes.  At this point, you can do one of \n> two things:\n>      (1) Decide it is Ok and say 'git checkout -f master';\n>      (2) Start a new branch from the current commit, by saying\n>          'git checkout -b <branch-name>'.\n>     Leaving your HEAD detached; not switching to branch 'master'.\n\nHere you have a detached HEAD, but you haven't build any commits\non top of it. Why shouldn't you be allowed to move away?\n\n-- \nbest regards\n\n  Ray\n"},{"id":"33218","messageId":"81b0412b0702010153m301a3603idc182df8abbf89a@mail.gmail.com","threadId":"6597","inReplyTo":"7vlkjip7mu.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] detached HEAD -- finishing touches","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-02-01T09:53:08Z","receivedAt":"2007-02-01T09:53:08Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/1/07, Junio C Hamano <junkio@cox.net> wrote:\n>     [git.git (master)]$ git checkout master^\n>     M       git-checkout.sh\n>     Note: you are not on any branch and are at commit \"master^\"\n>     If you want to create a new branch from this checkout, you may do so\n>     (now or later) by using -b with the checkout command again. Example:\n>       git checkout -b <new_branch_name>\n\nHow do you detach HEAD _without_ changing working tree at all?\nIOW, is there a \"git checkout --detach\"?\n"},{"id":"33219","messageId":"81b0412b0702010154v47b290act4e1c8d3722d23dd3@mail.gmail.com","threadId":"6597","inReplyTo":"81b0412b0702010153m301a3603idc182df8abbf89a@mail.gmail.com","subject":"Re: [PATCH] detached HEAD -- finishing touches","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-02-01T09:54:56Z","receivedAt":"2007-02-01T09:54:56Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 2/1/07, Alex Riesen <raa.lkml@gmail.com> wrote:\n> On 2/1/07, Junio C Hamano <junkio@cox.net> wrote:\n> >     [git.git (master)]$ git checkout master^\n> >     M       git-checkout.sh\n> >     Note: you are not on any branch and are at commit \"master^\"\n> >     If you want to create a new branch from this checkout, you may do so\n> >     (now or later) by using -b with the checkout command again. Example:\n> >       git checkout -b <new_branch_name>\n>\n> How do you detach HEAD _without_ changing working tree at all?\n> IOW, is there a \"git checkout --detach\"?\n>\n\nAh.. I see, the \"obscure, but useful trick\".\n"},{"id":"33229","messageId":"20070201124800.GA3863@moooo.ath.cx","threadId":"6597","inReplyTo":"200702010844.34500.andyparkins@gmail.com","subject":"Re: [PATCH] tone down the detached head warning","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2007-02-01T12:48:00Z","receivedAt":"2007-02-01T12:48:00Z","isPatch":true,"sender":{"key":"matled@gmx.net","avatar":null},"body":"Andy Parkins <andyparkins@gmail.com> wrote:\n> On Thursday 2007 February 01 00:14, Jakub Narebski wrote:\n> \n> > Although the fact that clone copies all branches and tags (I don't think\n> > there is a way to clone only subset of branches), and that fetch is multi\n> \n> There is, as long as you are willing to organise your branches in a consistent \n> way.  I keep all my branches with the prefix \"ap/\" then on another \n> development machine I just have\n> \n>  pull = refs/heads/ap/*:refs/heads/up/ap/*\n> \n> In my config.  This means I can make local branches that won't be grabbed \n> during the fetch, but still have branches automatically exported.\n> \n> This actually highlights a weakness in the globbing.  There is no way, for \n> example, to grab only unprefixed branches because the glob is blind to path \n> dividers (as is usual).  What would be even better would be a two glob \n> symbols, one meaning \"do cross separators\", one meaning \"don't\".  I think \n> rsync solves it for it's include/exclude patterns with a double asterisk.  \n> That is:\n> \n>  rsync -av --exclude \"foo/*/bar\" src/ dest/\n> \n> Would exclude anything called \"bar\" two levels under \"foo/\"; wheras\n> \n>  rsync -av --exclude \"foo/**/bar\" src/ dest/\n> \n> Would exclude anything called \"bar\" anywhere deeper than two levels \n> under \"foo\".\n> \n> I haven't thought of a good way of applying this in git though, and I have a \n> feeling that it could just complicate things excessively.\nfnmatch with FNM_PATHNAME disables * to match on / but it does not\nsupport the ** syntax afaik.\n"},{"id":"33267","messageId":"20070201184403.GA6326@moooo.ath.cx","threadId":"6597","inReplyTo":"7vlkjip7mu.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH] git-checkout: disable guides how to switch branches with ui.guide","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2007-02-01T18:44:03Z","receivedAt":"2007-02-01T18:44:03Z","isPatch":true,"sender":{"key":"matled@gmx.net","avatar":null},"body":"---\nJunio C Hamano <junkio@cox.net> wrote:\n> * Detaching head would say which commit I am at and reminds me that\n>   I am not on any branch (not that I would detach my HEAD while keeping\n>   precious local changes around in any real-world workflow -- this is\n>   just a sample session).\n> \n>     [git.git (master)]$ git checkout master^\n>     M       git-checkout.sh\n>     Note: you are not on any branch and are at commit \"master^\"\n>     If you want to create a new branch from this checkout, you may do so\n>     (now or later) by using -b with the checkout command again. Example:\n>       git checkout -b <new_branch_name>\n> \n> * Coming back to an attached state can lose the detached HEAD, so\n>   I get warned and stopped.\n> \n>     [git.git]$ git checkout master\n>     You are not on any branch and switching to branch 'master'\n>     may lose your changes.  At this point, you can do one of two things:\n>      (1) Decide it is Ok and say 'git checkout -f master';\n>      (2) Start a new branch from the current commit, by saying\n>          'git checkout -b <branch-name>'.\n>     Leaving your HEAD detached; not switching to branch 'master'.\nI think these two are too long, after a few times one knows exactly\nwhat to do and all this text is not necessary anymore.\n\nPerhaps the name (ui.guide) should be different, I just did not find\nany category to put this in.  The variable could become a general\nvariable to enable/disable very verbose explanations what to do in a\nsituation.\n---\n git-checkout.sh |   14 ++++++++++++--\n 1 files changed, 12 insertions(+), 2 deletions(-)\n\ndiff --git a/git-checkout.sh b/git-checkout.sh\nindex deb4795..1eb8b06 100755\n--- a/git-checkout.sh\n+++ b/git-checkout.sh\n@@ -5,6 +5,8 @@ SUBDIRECTORY_OK=Sometimes\n . git-sh-setup\n require_work_tree\n \n+guide=$(git repo-config --bool --get ui.guide)\n+[ -z \"$guide\" ] && guide=true\n old_name=HEAD\n old=$(git-rev-parse --verify $old_name 2>/dev/null)\n oldbranch=$(git-symbolic-ref $old_name 2>/dev/null)\n@@ -155,10 +157,13 @@ then\n \tdetached=\"$new\"\n \tif test -n \"$oldbranch\"\n \tthen\n-\t\tdetach_warn=\"Note: you are not on any branch and are at commit \\\"$new_name\\\"\n+\t\tdetach_warn=\"Note: you are not on any branch and are at commit \\\"$new_name\\\"\"\n+\t\tif test \"$guide\" = true; then\n+\t\t\tdetach_warn=\"$detach_warn\n If you want to create a new branch from this checkout, you may do so\n (now or later) by using -b with the checkout command again. Example:\n   git checkout -b <new_branch_name>\"\n+\t\tfi\n \tfi\n elif test -z \"$oldbranch\" && test -n \"$branch\"\n then\n@@ -166,13 +171,18 @@ then\n \tif test -z \"$force\"\n \tthen\n \t\tgit show-ref -d -s | grep \"$old\" >/dev/null || {\n-\t\t\techo >&2 \\\n+\t\t\tif test \"$guide\" = true; then\n+\t\t\t\techo >&2 \\\n \"You are not on any branch and switching to branch '$new_name'\n may lose your changes.  At this point, you can do one of two things:\n  (1) Decide it is Ok and say 'git checkout -f $new_name';\n  (2) Start a new branch from the current commit, by saying\n      'git checkout -b <branch-name>'.\n Leaving your HEAD detached; not switching to branch '$new_name'.\"\n+\t\t\telse\n+\t\t\t\techo >&2 \\\n+\"HEAD detached; use -f to switch to branch '$new_name'.\"\n+\t\t\tfi\n \t\t\texit 1;\n \t\t}\n \tfi\n-- \n1.5.0.rc3.g4a88\n"},{"id":"33276","messageId":"7vabzxpq2t.fsf@assigned-by-dhcp.cox.net","threadId":"6597","inReplyTo":"20070201184403.GA6326@moooo.ath.cx","subject":"Re: [PATCH] git-checkout: disable guides how to switch branches with ui.guide","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-01T20:42:34Z","receivedAt":"2007-02-01T20:42:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthias Lederhofer <matled@gmx.net> writes:\n\n>> * Coming back to an attached state can lose the detached HEAD, so\n>>   I get warned and stopped.\n>> \n>>     [git.git]$ git checkout master\n>>     You are not on any branch and switching to branch 'master'\n>>     may lose your changes.  At this point, you can do one of two things:\n>>      (1) Decide it is Ok and say 'git checkout -f master';\n>>      (2) Start a new branch from the current commit, by saying\n>>          'git checkout -b <branch-name>'.\n>>     Leaving your HEAD detached; not switching to branch 'master'.\n>\n> I think these two are too long, after a few times one knows exactly\n> what to do and all this text is not necessary anymore.\n\nI doubt adding a per-repo or per-user configuration would be\nworth it.\n\nThe original hope was after a few times one would know to use\neither -f or -b depending on what he wants, and would not run\nplain vanilla branch switching \"git checkout master\".\n\nThen one does not even have to see this message, not just the\nlast \"instruction\" lines but \"You are not on any branch\" part.\n"},{"id":"33277","messageId":"20070201205145.GA13439@moooo.ath.cx","threadId":"6597","inReplyTo":"7vabzxpq2t.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-checkout: disable guides how to switch branches with ui.guide","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2007-02-01T20:51:45Z","receivedAt":"2007-02-01T20:51:45Z","isPatch":true,"sender":{"key":"matled@gmx.net","avatar":null},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> The original hope was after a few times one would know to use\n> either -f or -b depending on what he wants, and would not run\n> plain vanilla branch switching \"git checkout master\".\nWhat is the point in detached heads if the user should start using -b\nafter a few times?  I think detached heads are useful, so I will not\nuse -b with it.\n"},{"id":"33285","messageId":"7vabzxoaed.fsf@assigned-by-dhcp.cox.net","threadId":"6597","inReplyTo":"20070201205145.GA13439@moooo.ath.cx","subject":"Re: [PATCH] git-checkout: disable guides how to switch branches with ui.guide","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-01T21:06:34Z","receivedAt":"2007-02-01T21:06:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthias Lederhofer <matled@gmx.net> writes:\n\n> Junio C Hamano <junkio@cox.net> wrote:\n>> The original hope was after a few times one would know to use\n>> either -f or -b depending on what he wants, and would not run\n>> plain vanilla branch switching \"git checkout master\".\n> What is the point in detached heads if the user should start using -b\n> after a few times?  I think detached heads are useful, so I will not\n> use -b with it.\n\nThe error message you quoted is given when your head is detached\nand you tried the regular \"checkout an existing branch\" -- which\nwill lose where your detached HEAD currently is.  You either say\n\"it's OK to lose it because I am done with it and I do not need\nto keep it anymore\" with \"-f\", or you say \"I am done with this\ndetached state for now, but I know I need to revisit it later\"\nwith \"-b\".\n\nSo if you will not use -b with it to discard a temporary state\nthat is detached HEAD, that is perfectly fine.  Detached head is\nuseful.\n"},{"id":"33288","messageId":"20070201212306.GA14152@moooo.ath.cx","threadId":"6597","inReplyTo":"7vabzxoaed.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-checkout: disable guides how to switch branches with ui.guide","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2007-02-01T21:23:06Z","receivedAt":"2007-02-01T21:23:06Z","isPatch":true,"sender":{"key":"matled@gmx.net","avatar":null},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> The error message you quoted [..]\nOk, I thought you were refering to the first one.  Right, for the\nsecond one it is ok, one will get used to do -b or -f.\n\nBut I also quoted (and patched) the other one for switching to\ndetached heads:\n> Note: you are not on any branch and are at commit \"v1.1.2\"\n> If you want to create a new branch from this checkout, you may do so\n> (now or later) by using -b with the checkout command again. Example:\n>   git checkout -b <new_branch_name>\nThis one is a bit shorter but the last three lines are still a guide\nwhat to do in case you don't know what's going an.\n"},{"id":"33290","messageId":"87ps8ta7fx.wl%cworth@cworth.org","threadId":"6597","inReplyTo":"7vabzxoaed.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-checkout: disable guides how to switch branches with ui.guide","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-02-01T21:34:10Z","receivedAt":"2007-02-01T21:34:10Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 01 Feb 2007 13:06:34 -0800, Junio C Hamano wrote:\n> The error message you quoted is given when your head is detached\n> and you tried the regular \"checkout an existing branch\" -- which\n> will lose where your detached HEAD currently is.\n\nI think the problem with this is that git tells the user so little\ninformation, (\"may lose your changes\"). What changes? Is that dirty\nstate?  Some commits? Hmm... have I committed anything? Why can't git\nbe sure about what this operation is going to do?\n\nI think a really useful message would be something like:\n\n\tYou are not on any branch so switching to branch 'foo'\n\twill cause the following commits to be lost:\n\n\t\tba531642 A commit headline here...\n\t\tb1189118 Another commit headline here...\n\n\tRefusing to checkout 'foo'.\n\nDidn't a bunch of work get committed to make the reachability analysis\nfeasible to generate a message like this?\n\nIf there are no commits that would become dangling, then the checkout\nshould just proceed. As for the concern about losing a pointer to some\n\"valuable\" state that will still technically be reachable, but might\nbe hard to get back, why not just print a message along the lines of:\n\n\tLeaving commit 7b1509f4 to checkout 'foo'.\n\n(or just depend on the HEAD reflog).\n\n-Carl\n\nPS. If nothing else gets changed in the current message, please\nreconsider the current wording of:\n\n\tLeaving your HEAD detached; not switching to branch 'foo'.\n\nThink: Wow, I had heard that git might help me shoot myself in the\nfoot, but I never though I might behead myself with it.\n\nIt would probably work to just reword that as:\n\n\tNot switching to branch 'foo'.\n"},{"id":"33292","messageId":"20070201215242.GA1775@thunk.org","threadId":"6597","inReplyTo":"7vlkjip7mu.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] detached HEAD -- finishing touches","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-02-01T21:52:42Z","receivedAt":"2007-02-01T21:52:42Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Feb 01, 2007 at 01:08:41AM -0800, Junio C Hamano wrote:\n>     [git.git]$ git checkout master\n>     You are not on any branch and switching to branch 'master'\n>     may lose your changes.  At this point, you can do one of two things:\n>      (1) Decide it is Ok and say 'git checkout -f master';\n>      (2) Start a new branch from the current commit, by saying\n>          'git checkout -b <branch-name>'.\n>     Leaving your HEAD detached; not switching to branch 'master'.\n\nHow hard would it be to simply simply set a flag once git has entered\na detached HEAD state, and clear the flag if any git operation has\nmodified the repository at all.  If the flag is still set, then\nobviously the repository hasn't changed and so there are no changes\nthat could be lost.  i.e., if I've do:\n\n<tytso@candygram> {/usr/projects/e2fsprogs/hg-to-git/test}  [master]\n181% git checkout 2ab15cafae661765ecd7f256b1993b94d5534faf\nwarning: you are not on ANY branch anymore.\nIf you meant to create a new branch from this checkout, you may still do\nso (now or later) by using -b with the checkout command again.  Example:\n  git checkout -b <new_branch_name>\n<tytso@candygram> {/usr/projects/e2fsprogs/hg-to-git/test}  \n182% git checkout master\nYou are not on any branch and switching to branch 'master'\nmay lose your changes.  At this point, you can do one of two things:\n (1) Decide it is Ok and say 'git checkout -f master';\n (2) Start a new branch from the current commit, by saying\n     'git checkout -b <branch-name>'.\nLeaving your HEAD detached; not switching to branch 'master'.\n\nIt's really obvious there are no changes, so it makes git seem a\nlittle stupid to always be saying \"may lose your changes\".  Can we\nsimply let git know that there weren't any changes?  \n\nOtherwise we're just training users to just always use the -f option.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"33293","messageId":"Pine.LNX.4.64.0702011656250.3021@xanadu.home","threadId":"6597","inReplyTo":"87ps8ta7fx.wl%cworth@cworth.org","subject":"Re: [PATCH] git-checkout: disable guides how to switch branches with ui.guide","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-01T21:59:46Z","receivedAt":"2007-02-01T21:59:46Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 1 Feb 2007, Carl Worth wrote:\n\n> I think the problem with this is that git tells the user so little\n> information, (\"may lose your changes\"). What changes? Is that dirty\n> state?  Some commits? Hmm... have I committed anything? Why can't git\n> be sure about what this operation is going to do?\n> \n> I think a really useful message would be something like:\n> \n> \tYou are not on any branch so switching to branch 'foo'\n> \twill cause the following commits to be lost:\n> \n> \t\tba531642 A commit headline here...\n> \t\tb1189118 Another commit headline here...\n> \n> \tRefusing to checkout 'foo'.\n\nPlease just display the last commit since this list could get long.\n\n> If there are no commits that would become dangling, then the checkout\n> should just proceed. As for the concern about losing a pointer to some\n> \"valuable\" state that will still technically be reachable, but might\n> be hard to get back, why not just print a message along the lines of:\n> \n> \tLeaving commit 7b1509f4 to checkout 'foo'.\n> \n> (or just depend on the HEAD reflog).\n\nIt is not fully available yet.\n\n\nNicolas\n"},{"id":"33298","messageId":"87ododa5gl.wl%cworth@cworth.org","threadId":"6597","inReplyTo":"Pine.LNX.4.64.0702011656250.3021@xanadu.home","subject":"Re: [PATCH] git-checkout: disable guides how to switch branches with ui.guide","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-02-01T22:16:58Z","receivedAt":"2007-02-01T22:16:58Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 01 Feb 2007 16:59:46 -0500 (EST), Nicolas Pitre wrote:\n> Please just display the last commit since this list could get long.\n\nIn that case what might be nice would be if it printed a revision\nspecification that could be handed to git-log or gitk for the user to\ninspect the situation.\n\nAnd extra nice if it looked like b1189118..ba531642 when possible.\n\n> > \tLeaving commit 7b1509f4 to checkout 'foo'.\n> >\n> > (or just depend on the HEAD reflog).\n>\n> It is not fully available yet.\n\nRight. I wasn't sure about when it is expected to come online. That's\nwhy I suggested the message above. It would be a very easy way to\nallow \"git checkout\" to work in the no-commits-to-lose case, but would\nstill give the user the name of the commit she is leaving behind in\ncase she wants to get back to it.\n\n-Carl\n\n"},{"id":"33306","messageId":"eptse3$cak$1@sea.gmane.org","threadId":"6597","inReplyTo":"87ododa5gl.wl%cworth@cworth.org","subject":"Re: [PATCH] git-checkout: disable guides how to switch branches with ui.guide","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-01T23:18:43Z","receivedAt":"2007-02-01T23:18:43Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Carl Worth wrote:\n\n> On Thu, 01 Feb 2007 16:59:46 -0500 (EST), Nicolas Pitre wrote:\n\n>> Please just display the last commit since this list could get long.\n> \n> In that case what might be nice would be if it printed a revision\n> specification that could be handed to git-log or gitk for the user to\n> inspect the situation.\n> \n> And extra nice if it looked like b1189118..ba531642 when possible.\n\nNice idea. Now only to come up with detailed wording...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"33322","messageId":"7v64alnz2q.fsf@assigned-by-dhcp.cox.net","threadId":"6597","inReplyTo":"20070201215242.GA1775@thunk.org","subject":"Re: [PATCH] detached HEAD -- finishing touches","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-02T01:11:09Z","receivedAt":"2007-02-02T01:11:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso <tytso@mit.edu> writes:\n\n> On Thu, Feb 01, 2007 at 01:08:41AM -0800, Junio C Hamano wrote:\n>>     [git.git]$ git checkout master\n>>     You are not on any branch and switching to branch 'master'\n>>     may lose your changes.  At this point, you can do one of two things:\n>>      (1) Decide it is Ok and say 'git checkout -f master';\n>>      (2) Start a new branch from the current commit, by saying\n>>          'git checkout -b <branch-name>'.\n>>     Leaving your HEAD detached; not switching to branch 'master'.\n>\n> How hard would it be to simply simply set a flag once git has entered\n> a detached HEAD state, and clear the flag if any git operation has\n> modified the repository at all.  If the flag is still set, then\n> obviously the repository hasn't changed and so there are no changes\n> that could be lost.\n\nDidn't I already point out that you can have a precious\ninformation while on the detached HEAD without making any\ncommit, and that is the reason why we do not use the\nreachability crud from refs when deciding to issue the message?\n"},{"id":"33324","messageId":"20070202011608.GA18880@thunk.org","threadId":"6597","inReplyTo":"7v64alnz2q.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] detached HEAD -- finishing touches","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-02-02T01:16:09Z","receivedAt":"2007-02-02T01:16:09Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Feb 01, 2007 at 05:11:09PM -0800, Junio C Hamano wrote:\n> Didn't I already point out that you can have a precious\n> information while on the detached HEAD without making any\n> commit, and that is the reason why we do not use the\n> reachability crud from refs when deciding to issue the message?\n\nSorry, I must be dense.  Exactly what precious information can be ever\nbe lost in the following sequence:\n\ngit checkout HEAD~1\ngit checkout master\n\nsuch that it want to train users to be typing\n\ngit checkout -f master\n\ninstead?\n\n\t\t\t\t\t\t- Ted\n"},{"id":"33326","messageId":"87ejp99wn7.wl%cworth@cworth.org","threadId":"6597","inReplyTo":"7v64alnz2q.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] detached HEAD -- finishing touches","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-02-02T01:27:24Z","receivedAt":"2007-02-02T01:27:24Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 01 Feb 2007 17:11:09 -0800, Junio C Hamano wrote:\n> Didn't I already point out that you can have a precious\n> information while on the detached HEAD without making any\n> commit, and that is the reason why we do not use the\n> reachability crud from refs when deciding to issue the message?\n\nI recognize that a specification of the current commit could be\nprecious, (as mentioned in a thread talking about the possibility of\ngit-bisect using detached head rather than a branch).\n\nAnd that's why I proposed a checkout away from detached head just\nprinting the name of the commit that was being left.\n\nIs there any other precious information that that solution would not\naddress?\n\n-Carl\n"},{"id":"33327","messageId":"7virelmjlr.fsf@assigned-by-dhcp.cox.net","threadId":"6597","inReplyTo":"87ejp99wn7.wl%cworth@cworth.org","subject":"Re: [PATCH] detached HEAD -- finishing touches","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-02T01:30:40Z","receivedAt":"2007-02-02T01:30:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth <cworth@cworth.org> writes:\n\n> And that's why I proposed a checkout away from detached head just\n> printing the name of the commit that was being left.\n>\n> Is there any other precious information that that solution would not\n> address?\n\nI do not think of any offhand, but \"did we make commit since we\ndetached HEAD\" was not a suggestion I made, so what I can think\nof does not matter much ;-).\n"},{"id":"33329","messageId":"87d54t9vs7.wl%cworth@cworth.org","threadId":"6597","inReplyTo":"7virelmjlr.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] detached HEAD -- finishing touches","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-02-02T01:46:00Z","receivedAt":"2007-02-02T01:46:00Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 01 Feb 2007 17:30:40 -0800, Junio C Hamano wrote:\n> I do not think of any offhand, but \"did we make commit since we\n> detached HEAD\" was not a suggestion I made, so what I can think\n> of does not matter much ;-).\n\nWell, the suggestion I made was to:\n\n1. Print the name of the commit we are leaving\n\n2. Refuse to leave if what we are leaving would leave commits\n   dangling, (and print a revision specification for those set of\n   commits).\n\nDo you have a reaction to that?\n\n-Carl\n"},{"id":"33332","messageId":"7vwt31l1vo.fsf@assigned-by-dhcp.cox.net","threadId":"6597","inReplyTo":"87d54t9vs7.wl%cworth@cworth.org","subject":"Re: [PATCH] detached HEAD -- finishing touches","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-02T02:38:51Z","receivedAt":"2007-02-02T02:38:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth <cworth@cworth.org> writes:\n\n> On Thu, 01 Feb 2007 17:30:40 -0800, Junio C Hamano wrote:\n>> I do not think of any offhand, but \"did we make commit since we\n>> detached HEAD\" was not a suggestion I made, so what I can think\n>> of does not matter much ;-).\n>\n> Well, the suggestion I made was to:\n>\n> 1. Print the name of the commit we are leaving\n>\n> 2. Refuse to leave if what we are leaving would leave commits\n>    dangling, (and print a revision specification for those set of\n>    commits).\n>\n> Do you have a reaction to that?\n\nNot having thought things through, I am very tempted to say that\nwe can leave things as they are, and when the reflog for HEAD\nmaterializes, just remove the check from the codepath that makes\nyour HEAD point at an existing branch again.  With the reflog on\nHEAD, you do not need to be reminded of which commit you are\nleaving so there is no need for 1 above, and you would not lose\nyour point (either connected or disconnected) so there is no\nneed for 2 above either.\n"}]}