{"thread":{"id":"26479","subject":"[PATCH] git-gui: give more advice when detaching HEAD","startedAt":"2011-02-12T07:05:38Z","lastAt":"2011-02-17T23:13:27Z","messageCount":19,"participants":["Jeff King","Junio C Hamano","Sverre Rabbelier","Johannes Sixt","Heiko Voigt","Pat Thoyts","Victor Engmark"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"160932","messageId":"20110212070538.GA2459@sigill.intra.peff.net","threadId":"26479","inReplyTo":null,"subject":"[PATCH] git-gui: give more advice when detaching HEAD","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-12T07:05:38Z","receivedAt":"2011-02-12T07:05:38Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"The current advice is a little sparse and dates back to\nd41b43e (git-gui: Refactor branch switch to support detached\nhead, 2007-07-08). In the meantime, command-line git grew\nmuch more detailed advice for this situation, especially in\n13be3e3 (Reword \"detached HEAD\" notification, 2010-01-29).\n\nLet's use that more detailed advice here.\n\nSigned-off-by: Jeff King \n---\nI recently helped somebody who had detached HEAD via git-gui, made a\nbunch of commits, switched to another branch, and then became confused\nabout where his work went.\n\nAfter working through what happened with him, I think this is one place\nwhere we could have prevented the problem. And given that we saw the\nneed for more advice in the CLI, I think this change is a no-brainer.\n\nI also think we could have saved him by doing one or more of:\n\n 1. Give some indication or warning during commit that you're in a\n detached state. The CLI template says \"You are not on any branch\"\n when editing the commit message, and mentions \"detached HEAD\" as\n the branch in the post-commit summary. As far as I can tell,\n git-gui says nothing at all.\n\n 2. When leaving the detached state, notice that we have commits not\n contained in any other ref and pop up an \"are you sure you want to\n lose these commits\" dialog, with an option to create a branch. This\n is something we considered and rejected for the CLI, but I wonder\n if it makes more sense for git-gui.\n\n 3. Make it easier to create a new branch from the checkout dialog.\n Obviously I can go to \"Branch->Create\" and make a new branch from a\n remote one. But if my mental model is \"Checkout\", then I pick a\n remote branch, we may want to present the user with the decision\n _then_ about detaching or creating. Something as simple as a \"make\n local branch from remote\" checkbox would help. Or perhaps the\n \"you're going to a detached HEAD\" dialog should actually have a\n button to create a local branch right then and there instead. I\n dunno.\n\nAll of those things are too far beyond my scope of caring about git-gui\nand wanting to write tcl to actually implement myself. But I thought I\nwould share them as thoughts that came from a real confused-user\ninteraction. Feel free to ignore.\n\n lib/checkout_op.tcl | 13 ++++++++++---\n 1 files changed, 10 insertions(+), 3 deletions(-)\n\ndiff --git a/lib/checkout_op.tcl b/lib/checkout_op.tcl\nindex 9e7412c..9c95208 100644\n--- a/lib/checkout_op.tcl\n+++ b/lib/checkout_op.tcl\n@@ -449,9 +449,16 @@ method _after_readtree {} {\n \t}\n \n \tif {$is_detached} {\n-\t\tinfo_popup [mc \"You are no longer on a local branch.\n-\n-If you wanted to be on a branch, create one now starting from 'This Detached Checkout'.\"]\n+\t\tinfo_popup [mc \\\n+\"You are no longer on a local branch. You can look\n+around, make experimental changes and commit,\n+and you can discard any commits you make in this\n+state without impacting any branches by\n+performing another checkout.\n+\n+If you want to create a new branch to retain\n+commits you create, you may do so (now or later)\n+by starting from 'This Detached Checkout'.\"]\n \t}\n \n \t# -- Run the post-checkout hook.\n-- \n1.7.4\n"},{"id":"160933","messageId":"7v8vxlzojs.fsf@alter.siamese.dyndns.org","threadId":"26479","inReplyTo":"20110212070538.GA2459@sigill.intra.peff.net","subject":"Re: [PATCH] git-gui: give more advice when detaching HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-12T07:42:47Z","receivedAt":"2011-02-12T07:42:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> 2. When leaving the detached state, notice that we have commits not\n> contained in any other ref and pop up an \"are you sure you want to\n> lose these commits\" dialog, with an option to create a branch. This\n> is something we considered and rejected for the CLI, but I wonder\n> if it makes more sense for git-gui.\n\nHmm, I don't recall the discussion on this for the CLI, but it intuitively\nfeels like a good thing to do, unless it incurs an unacceptable cost.\nTemporarily detaching HEAD by scripts like rebase and am that know what\nthey are doing should never have to pay the penalty, but an expert user\nwho worked interactively on the detached HEAD can be made to wait for 0.2\nsecond more.\n\nYour 1 and 3 both sound like sensible things to do, but I am not a good\njudge on them as I rarely if ever work in GUI.\n"},{"id":"160935","messageId":"20110212080456.GA18380@sigill.intra.peff.net","threadId":"26479","inReplyTo":"7v8vxlzojs.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-gui: give more advice when detaching HEAD","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-12T08:04:57Z","receivedAt":"2011-02-12T08:04:57Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 11, 2011 at 11:42:47PM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > 2. When leaving the detached state, notice that we have commits not\n> > contained in any other ref and pop up an \"are you sure you want to\n> > lose these commits\" dialog, with an option to create a branch. This\n> > is something we considered and rejected for the CLI, but I wonder\n> > if it makes more sense for git-gui.\n> \n> Hmm, I don't recall the discussion on this for the CLI, but it intuitively\n> feels like a good thing to do, unless it incurs an unacceptable cost.\n\nI think one of the main concerns was cost, but I'm having trouble coming\nup with the exact thread that I recall.\n\nThere is some discussion here, including Linus endorsing an exact-ref\ncheck:\n\n http://article.gmane.org/gmane.comp.version-control.git/36428\n\nThere is a lot of back and forth, but I didn't have the patience to read\nit all.\n\nThere is also this thread:\n\n http://thread.gmane.org/gmane.comp.version-control.git/94695\n\nwhere one of the arguments against a leaving-detached safety valve seems\nto be \"well, we reflog the HEAD these days, so it's no big deal\" (and\nindeed, in this confused user case, the reflog did end up being the\nrecovery method).\n\nI have a feeling there is another thread somewhere, but I can't find it.\n\n> Temporarily detaching HEAD by scripts like rebase and am that know what\n> they are doing should never have to pay the penalty, but an expert user\n> who worked interactively on the detached HEAD can be made to wait for 0.2\n> second more.\n\nIs it that cheap? A full reachability check for something that is not in\nany ref would involve going to the roots, wouldn't it? On linux-2.6,\nthat is something like 3s on my fast-ish machine. Though I guess using\ncommit-time cutoffs could make it really short (which reminds me, I\nreally need to clean up and post my patches to deal with clock skew).\n\n> Your 1 and 3 both sound like sensible things to do, but I am not a good\n> judge on them as I rarely if ever work in GUI.\n\nThat's kind of how I feel. I've never actually used git-gui beyond\ntrying to help users.\n\n-Peff\n"},{"id":"160937","messageId":"7vzkq1y8dv.fsf@alter.siamese.dyndns.org","threadId":"26479","inReplyTo":"20110212080456.GA18380@sigill.intra.peff.net","subject":"Re: [PATCH] git-gui: give more advice when detaching HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-12T08:17:16Z","receivedAt":"2011-02-12T08:17:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Is it that cheap? A full reachability check for something that is not in\n> any ref would involve going to the roots, wouldn't it?\n\nYou only need to dig until you hit a merge base, no?\n\nIn this case, you would need to compute just one merge base, between the\ncommit you are about to leave, and the (imaginary) commit that is a merge\nacross all the tips of your refs. If the merge base is the commit you are\nabout to leave, you were sightseeing in the past without creating anything\nnew, otherwise you will lose commits between the computed base and the\ncommit you are about to leave.\n\nAnd merge-base has an interface to compute exactly that, I think.\n"},{"id":"160938","messageId":"20110212082108.GA19656@sigill.intra.peff.net","threadId":"26479","inReplyTo":"7vzkq1y8dv.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-gui: give more advice when detaching HEAD","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-12T08:21:08Z","receivedAt":"2011-02-12T08:21:08Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Feb 12, 2011 at 12:17:16AM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > Is it that cheap? A full reachability check for something that is not in\n> > any ref would involve going to the roots, wouldn't it?\n> \n> You only need to dig until you hit a merge base, no?\n\nHmm, yeah, you're right. In the worst case of reachability checks, you\nwould share no ancestry and go to the roots searching for the merge\nbase, but of course that is very unlikely to be the case here. So it\nshould be much cheaper.\n\n> And merge-base has an interface to compute exactly that, I think.\n\nWant to do a proof-of-concept patch? Then we can get some real timings.\n\n-Peff\n"},{"id":"160942","messageId":"7voc6hy771.fsf@alter.siamese.dyndns.org","threadId":"26479","inReplyTo":"7vzkq1y8dv.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-gui: give more advice when detaching HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-12T08:42:58Z","receivedAt":"2011-02-12T08:42:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> You only need to dig until you hit a merge base, no?\n> ...\n> And merge-base has an interface to compute exactly that, I think.\n\nAh, forget \"merge-base\". In the kernel repository, the very old \"v2.6.12\"\nwill participate in the (imaginary) merge across all the refs, and\ncomputing merge-base means we need to traverse down to it.\n\nWe only need to prime a \"struct revisions\" with the detached HEAD as the\nsole positive, and the refs as negatives (i.e. UNINTERESTING), and walk\nthe history the usual way, until we either\n\n (1) see HEAD painted uninteresting; or\n (2) the queue becomes all uninteresting.\n\nAs soon as (1) happens, we know the HEAD is reachable from some ref, and\nwe can immediately stop. When (2) happens, we inspect the HEAD again and\nif it is painted uninteresting then we know HEAD is reachable from some\nref. Otherwise HEAD will become dangling when you leave it.\n\nThat way, the traversal will terminate much sooner than computing the true\nmerge base.\n"},{"id":"160969","messageId":"AANLkTi=3m3pvciKXgUXGffsA9xDddTum5mhWBoaWA3o+@mail.gmail.com","threadId":"26479","inReplyTo":"7voc6hy771.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-gui: give more advice when detaching HEAD","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-02-13T00:05:41Z","receivedAt":"2011-02-13T00:05:41Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Sat, Feb 12, 2011 at 09:42, Junio C Hamano wrote:\n> That way, the traversal will terminate much sooner than computing the true\n> merge base.\n\nSince we want to use this in git-gui, do you intend to expose this as\na command somehow (e.g. 'git rev-parse --reachable HEAD --all' or\nsomesuch)?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"160984","messageId":"201102131022.06863.j6t@kdbg.org","threadId":"26479","inReplyTo":"AANLkTi=3m3pvciKXgUXGffsA9xDddTum5mhWBoaWA3o+@mail.gmail.com","subject":"Re: [PATCH] git-gui: give more advice when detaching HEAD","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2011-02-13T09:22:06Z","receivedAt":"2011-02-13T09:22:06Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Sonntag, 13. Februar 2011, Sverre Rabbelier wrote:\n> Heya,\n>\n> On Sat, Feb 12, 2011 at 09:42, Junio C Hamano wrote:\n> > That way, the traversal will terminate much sooner than computing the\n> > true merge base.\n>\n> Since we want to use this in git-gui, do you intend to expose this as\n> a command somehow (e.g. 'git rev-parse --reachable HEAD --all' or\n> somesuch)?\n\nWhat's wrong with checking the output of\n\n git rev-list -1 HEAD --not --branches --tags --\n\nfor zero length?\n\n-- Hannes\n"},{"id":"160998","messageId":"20110213123151.GA31375@book.hvoigt.net","threadId":"26479","inReplyTo":"20110212070538.GA2459@sigill.intra.peff.net","subject":"Re: [PATCH] git-gui: give more advice when detaching HEAD","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-02-13T12:31:52Z","receivedAt":"2011-02-13T12:31:52Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Sat, Feb 12, 2011 at 02:05:38AM -0500, Jeff King wrote:\n> 1. Give some indication or warning during commit that you're in a\n> detached state. The CLI template says \"You are not on any branch\"\n> when editing the commit message, and mentions \"detached HEAD\" as\n> the branch in the post-commit summary. As far as I can tell,\n> git-gui says nothing at all.\n\nHow about something like this:\n\n---8<----\nFrom 8e2b61cd5e8d85f43ed6f00935a757f0dfa56b3b Mon Sep 17 00:00:00 2001\nFrom: Heiko Voigt \nDate: Sun, 13 Feb 2011 13:25:04 +0100\nSubject: [PATCH] git-gui: warn when trying to commit on a detached head\n\nThe commandline is already warning when checking out a detached head.\nSince the only thing thats potentially dangerous is to create commits\non a detached head lets warn in case the user is about to do that.\n\nSigned-off-by: Heiko Voigt \n---\nThe wording of the warning might need some cleanup and documentation of\nthe configuration variable is still missing but if you like it I will\nadd it.\n\n git-gui/git-gui.sh | 1 +\n git-gui/lib/commit.tcl | 14 ++++++++++++++\n 2 files changed, 15 insertions(+), 0 deletions(-)\n\ndiff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh\nindex d3acf0d..5314a3f 100755\n--- a/git-gui/git-gui.sh\n+++ b/git-gui/git-gui.sh\n@@ -831,6 +831,7 @@ set default_config(gui.fontdiff) [font configure font_diff]\n # TODO: this option should be added to the git-config documentation\n set default_config(gui.maxfilesdisplayed) 5000\n set default_config(gui.usettk) 1\n+set default_config(gui.warndetachedcommit) 1\n set font_descs {\n \t{fontui font_ui {mc \"Main Font\"}}\n \t{fontdiff font_diff {mc \"Diff/Console Font\"}}\ndiff --git a/git-gui/lib/commit.tcl b/git-gui/lib/commit.tcl\nindex 7f459cd..9bef8ee 100644\n--- a/git-gui/lib/commit.tcl\n+++ b/git-gui/lib/commit.tcl\n@@ -259,8 +259,22 @@ proc commit_prehook_wait {fd_ph curHEAD msg_p} {\n }\n \n proc commit_commitmsg {curHEAD msg_p} {\n+\tglobal is_detached repo_config\n \tglobal pch_error\n \n+\tif {$is_detached && $repo_config(gui.warndetachedcommit)} {\n+\t\tset msg [mc \"You are about to commit on a detached head.\n+This is a potentially dangerous thing to do because\n+if you switch to another branch you will loose your\n+changes and it can be difficult to get them back.\n+\n+Do you really want to proceed?\"]\n+\t\tif {[ask_popup $msg] ne yes} {\n+\t\t\tunlock_index\n+\t\t\treturn\n+\t\t}\n+\t}\n+\n \t# -- Run the commit-msg hook.\n \t#\n \tset fd_ph [githook_read commit-msg $msg_p]\n-- \n1.7.4.rc3.4.g155c4\n"},{"id":"161016","messageId":"7v4o87wmxl.fsf@alter.siamese.dyndns.org","threadId":"26479","inReplyTo":"201102131022.06863.j6t@kdbg.org","subject":"Re: [PATCH] git-gui: give more advice when detaching HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-13T23:10:30Z","receivedAt":"2011-02-13T23:10:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n>> On Sat, Feb 12, 2011 at 09:42, Junio C Hamano wrote:\n>> > That way, the traversal will terminate much sooner than computing the\n>> > true merge base.\n>>\n>> Since we want to use this in git-gui, do you intend to expose this as\n>> a command somehow (e.g. 'git rev-parse --reachable HEAD --all' or\n>> somesuch)?\n>\n> What's wrong with checking the output of\n>\n> git rev-list -1 HEAD --not --branches --tags --\n>\n> for zero length?\n\nNothing, except that (1) that approach won't catch refs outside heads and\ntags (like the ones I have in refs/merge-fixes and refs/hold), and (2) it\nwon't have an early termination optimization I mentioned either.\n\nI don't know how much the early termination optimization matter in\npractice, though. It would probably depend heavily on where you begin.\n"},{"id":"161150","messageId":"20110215063903.GA28634@sigill.intra.peff.net","threadId":"26479","inReplyTo":"20110213123151.GA31375@book.hvoigt.net","subject":"Re: [PATCH] git-gui: give more advice when detaching HEAD","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-15T06:39:03Z","receivedAt":"2011-02-15T06:39:03Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 13, 2011 at 01:31:52PM +0100, Heiko Voigt wrote:\n\n> On Sat, Feb 12, 2011 at 02:05:38AM -0500, Jeff King wrote:\n> > 1. Give some indication or warning during commit that you're in a\n> > detached state. The CLI template says \"You are not on any branch\"\n> > when editing the commit message, and mentions \"detached HEAD\" as\n> > the branch in the post-commit summary. As far as I can tell,\n> > git-gui says nothing at all.\n> \n> How about something like this:\n> [...]\n> Subject: [PATCH] git-gui: warn when trying to commit on a detached head\n> \n> The commandline is already warning when checking out a detached head.\n> Since the only thing thats potentially dangerous is to create commits\n> on a detached head lets warn in case the user is about to do that.\n\nIt seems a little heavy-handed to have a dialog pop up for each commit.\nIt's not actually dangerous to create a commit on a detached HEAD; it's\njust dangerous to _leave_ without referencing your new commits.\n\nSo I think for making commits, something informational that doesn't\nrequire a click-through would be the more appropriate level (similar to\nwhat the CLI does; it just mentions it in the commit template). I guess\nthere isn't a commit template in the same way for git gui; instead, it\nis always showing you the current state. And indeed, it does switch from\n\"Current Branch: master\" to \"Current Branch: HEAD\" when you are on a\ndetached head. Maybe we should beef that up a bit to \"You are not on any\nbranch.\" or something that is more self-explanatory. I dunno. I am just\nguessing here about what users would want.\n\nI do think a pop-up is appropriate when you try to check something else\nout, and commits you have made on the detached HEAD are about to become\nunreferenced. But this is something even the CLI doesn't do, so it would\nmake sense to see how the check is implemented there first before doing\nanything in git-gui.\n\n-Peff\n"},{"id":"161204","messageId":"20110215191620.GA56397@book.hvoigt.net","threadId":"26479","inReplyTo":"20110215063903.GA28634@sigill.intra.peff.net","subject":"Re: Re: [PATCH] git-gui: give more advice when detaching HEAD","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-02-15T19:16:21Z","receivedAt":"2011-02-15T19:16:21Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Tue, Feb 15, 2011 at 01:39:03AM -0500, Jeff King wrote:\n> On Sun, Feb 13, 2011 at 01:31:52PM +0100, Heiko Voigt wrote:\n> \n> > On Sat, Feb 12, 2011 at 02:05:38AM -0500, Jeff King wrote:\n> > > 1. Give some indication or warning during commit that you're in a\n> > > detached state. The CLI template says \"You are not on any branch\"\n> > > when editing the commit message, and mentions \"detached HEAD\" as\n> > > the branch in the post-commit summary. As far as I can tell,\n> > > git-gui says nothing at all.\n> > \n> > How about something like this:\n> > [...]\n> > Subject: [PATCH] git-gui: warn when trying to commit on a detached head\n> > \n> > The commandline is already warning when checking out a detached head.\n> > Since the only thing thats potentially dangerous is to create commits\n> > on a detached head lets warn in case the user is about to do that.\n> \n> It seems a little heavy-handed to have a dialog pop up for each commit.\n> It's not actually dangerous to create a commit on a detached HEAD; it's\n> just dangerous to _leave_ without referencing your new commits.\n\nHmm, how about adding a checkbox:\n\n [ ] Do not ask again\n\nIn my experience anything other than a popup will be overseen so I would\nsuggest doing it at least once to prepare the user for the possible\nconsequences.\n\nIMO such a message is a good thing for the GUI regardless whether we\nimplement the leaving detached HEAD state warning. First I think a\ntypical GUI user does not commit on a detached head that often since\nthere is currently no way to use these commits from the GUI (e.g.\nformat-patch, rebase, ...). Second because a detached head is very\npractical for testing work on a remote branch the message box would\nremind most users to switch to their development branch first. If they\nonly get that message after a series of commits it might become a hassle\nfor them to get these commits onto another branch (remember no\nformat-patch or rebase currently).\n\n> So I think for making commits, something informational that doesn't\n> require a click-through would be the more appropriate level (similar to\n> what the CLI does; it just mentions it in the commit template). I guess\n> there isn't a commit template in the same way for git gui; instead, it\n> is always showing you the current state. And indeed, it does switch from\n> \"Current Branch: master\" to \"Current Branch: HEAD\" when you are on a\n> detached head. Maybe we should beef that up a bit to \"You are not on any\n> branch.\" or something that is more self-explanatory. I dunno. I am just\n> guessing here about what users would want.\n> \n> I do think a pop-up is appropriate when you try to check something else\n> out, and commits you have made on the detached HEAD are about to become\n> unreferenced. But this is something even the CLI doesn't do, so it would\n> make sense to see how the check is implemented there first before doing\n> anything in git-gui.\n\n>From what I read in this thread it currently seems to be not so easy to\nprecisely find out whether some commit is referenced. (If we care about\nstuff outside of remotes, heads and tags). But maybe we do not need\nthat for the GUI.\n\nIf a commit is referenced from non typical refs the worst we do is issue\na false warning. Meaning we warn the user even though the commit is\nreferenced. For a GUI I think being a little more restrictive is the\nright thing to do since it should guide the user much more into a safe\nworkflow. If he wants to do special things than there still is the CLI\nto fall back on. And its just a warning so we are not preventing\nanything.\n\nNow it depends on what we would want for the CLI if we are going to\nimplement a thorough check over everything in refs/ than there is no\nreason for not applying the same thing to git-gui. In case the current\nbehavior is deemed sufficient we should go with the check mention\n\nJust to give you a practical example:\n\nAt $dayjob we are currently even more restrictive and completely forbid\ncommits on a detached head by a pre-commit hook. This was mainly done\ndue to the lack of warnings but I do not recall a single incident where a\nuser actually complained about this restriction (~90% GUI users).\n\nCheers Heiko\n"},{"id":"161206","messageId":"87pqqtaxke.fsf@fox.patthoyts.tk","threadId":"26479","inReplyTo":"20110215191620.GA56397@book.hvoigt.net","subject":"Re: [PATCH] git-gui: give more advice when detaching HEAD","fromName":"Pat Thoyts","fromEmail":"patthoyts@users.sourceforge.net","sentAt":"2011-02-15T19:48:33Z","receivedAt":"2011-02-15T19:48:33Z","isPatch":true,"sender":{"key":"patthoyts@users.sourceforge.net","avatar":"https://avatars.githubusercontent.com/u/30739?v=4"},"body":"From: Heiko Voigt \nDate: Tue, 15 Feb 2011 19:43:54 +0000\nSubject: [PATCH] git-gui: warn when trying to commit on a detached head\n\nThe commandline is already warning when checking out a detached head.\nSince the only thing thats potentially dangerous is to create commits\non a detached head lets warn in case the user is about to do that.\n\nSigned-off-by: Heiko Voigt \nSigned-off-by: Pat Thoyts \n---\n\nHeiko Voigt writes:\n>Hi,\n>\n>On Tue, Feb 15, 2011 at 01:39:03AM -0500, Jeff King wrote:\n>> On Sun, Feb 13, 2011 at 01:31:52PM +0100, Heiko Voigt wrote:\n>> \n>> > On Sat, Feb 12, 2011 at 02:05:38AM -0500, Jeff King wrote:\n>> > > 1. Give some indication or warning during commit that you're in a\n>> > > detached state. The CLI template says \"You are not on any branch\"\n>> > > when editing the commit message, and mentions \"detached HEAD\" as\n>> > > the branch in the post-commit summary. As far as I can tell,\n>> > > git-gui says nothing at all.\n>> > \n>> > How about something like this:\n>> > [...]\n>> > Subject: [PATCH] git-gui: warn when trying to commit on a detached head\n>> > \n>> > The commandline is already warning when checking out a detached head.\n>> > Since the only thing thats potentially dangerous is to create commits\n>> > on a detached head lets warn in case the user is about to do that.\n>> \n>> It seems a little heavy-handed to have a dialog pop up for each commit.\n>> It's not actually dangerous to create a commit on a detached HEAD; it's\n>> just dangerous to _leave_ without referencing your new commits.\n>\n>Hmm, how about adding a checkbox:\n>\n> [ ] Do not ask again\n>\n>In my experience anything other than a popup will be overseen so I would\n>suggest doing it at least once to prepare the user for the possible\n>consequences.\n>\n>IMO such a message is a good thing for the GUI regardless whether we\n>implement the leaving detached HEAD state warning. First I think a\n>typical GUI user does not commit on a detached head that often since\n>there is currently no way to use these commits from the GUI (e.g.\n>format-patch, rebase, ...). Second because a detached head is very\n>practical for testing work on a remote branch the message box would\n>remind most users to switch to their development branch first. If they\n>only get that message after a series of commits it might become a hassle\n>for them to get these commits onto another branch (remember no\n>format-patch or rebase currently).\n>\n>> So I think for making commits, something informational that doesn't\n>> require a click-through would be the more appropriate level (similar to\n>> what the CLI does; it just mentions it in the commit template). I guess\n>> there isn't a commit template in the same way for git gui; instead, it\n>> is always showing you the current state. And indeed, it does switch from\n>> \"Current Branch: master\" to \"Current Branch: HEAD\" when you are on a\n>> detached head. Maybe we should beef that up a bit to \"You are not on any\n>> branch.\" or something that is more self-explanatory. I dunno. I am just\n>> guessing here about what users would want.\n>> \n>> I do think a pop-up is appropriate when you try to check something else\n>> out, and commits you have made on the detached HEAD are about to become\n>> unreferenced. But this is something even the CLI doesn't do, so it would\n>> make sense to see how the check is implemented there first before doing\n>> anything in git-gui.\n>\n>From what I read in this thread it currently seems to be not so easy to\n>precisely find out whether some commit is referenced. (If we care about\n>stuff outside of remotes, heads and tags). But maybe we do not need\n>that for the GUI.\n>\n>If a commit is referenced from non typical refs the worst we do is issue\n>a false warning. Meaning we warn the user even though the commit is\n>referenced. For a GUI I think being a little more restrictive is the\n>right thing to do since it should guide the user much more into a safe\n>workflow. If he wants to do special things than there still is the CLI\n>to fall back on. And its just a warning so we are not preventing\n>anything.\n>\n>Now it depends on what we would want for the CLI if we are going to\n>implement a thorough check over everything in refs/ than there is no\n>reason for not applying the same thing to git-gui. In case the current\n>behavior is deemed sufficient we should go with the check mention\n>\n>Just to give you a practical example:\n>\n>At $dayjob we are currently even more restrictive and completely forbid\n>commits on a detached head by a pre-commit hook. This was mainly done\n>due to the lack of warnings but I do not recall a single incident where a\n>user actually complained about this restriction (~90% GUI users).\n>\n>Cheers Heiko\n\nMy feeling is that the user should be making a branch to hold his\ncommits. So I suggest adding some text to suggest that a branch be\ncreated and keep annoying the user every time they commit to a detached\nhead. This errs on the side of not dropping commits into the reflog\nwhich seems the most useful strategy to me.\n\nSo here is a modded version of Heiko's patch.\n\n git-gui.sh | 1 +\n lib/commit.tcl | 15 +++++++++++++++\n 2 files changed, 16 insertions(+), 0 deletions(-)\n\ndiff --git a/git-gui.sh b/git-gui.sh\nindex d96df63..9f2e9ae 100755\n--- a/git-gui.sh\n+++ b/git-gui.sh\n@@ -835,6 +835,7 @@ set default_config(gui.fontdiff) [font configure font_diff]\n # TODO: this option should be added to the git-config documentation\n set default_config(gui.maxfilesdisplayed) 5000\n set default_config(gui.usettk) 1\n+set default_config(gui.warndetachedcommit) 1\n set font_descs {\n \t{fontui font_ui {mc \"Main Font\"}}\n \t{fontdiff font_diff {mc \"Diff/Console Font\"}}\ndiff --git a/lib/commit.tcl b/lib/commit.tcl\nindex 5ce4687..372bed9 100644\n--- a/lib/commit.tcl\n+++ b/lib/commit.tcl\n@@ -260,8 +260,23 @@ proc commit_prehook_wait {fd_ph curHEAD msg_p} {\n }\n \n proc commit_commitmsg {curHEAD msg_p} {\n+\tglobal is_detached repo_config\n \tglobal pch_error\n \n+\tif {$is_detached && $repo_config(gui.warndetachedcommit)} {\n+\t\tset msg [mc \"You are about to commit on a detached head.\\\n+This is a potentially dangerous thing to do because if you switch\\\n+to another branch you will loose your changes and it can be difficult\\\n+to retrieve them later from the reflog. You should probably cancel this\\\n+commit and create a new branch to continue.\\n\\\n+\\n\\\n+Do you really want to proceed with your commit?\"]\n+\t\tif {[ask_popup $msg] ne yes} {\n+\t\t\tunlock_index\n+\t\t\treturn\n+\t\t}\n+\t}\n+\n \t# -- Run the commit-msg hook.\n \t#\n \tset fd_ph [githook_read commit-msg $msg_p]\n-- \n1.7.4.1\n"},{"id":"161258","messageId":"20110216034606.GA2414@sigill.intra.peff.net","threadId":"26479","inReplyTo":"20110215191620.GA56397@book.hvoigt.net","subject":"Re: Re: [PATCH] git-gui: give more advice when detaching HEAD","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-16T03:46:06Z","receivedAt":"2011-02-16T03:46:06Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 15, 2011 at 08:16:21PM +0100, Heiko Voigt wrote:\n\n> > It seems a little heavy-handed to have a dialog pop up for each commit.\n> > It's not actually dangerous to create a commit on a detached HEAD; it's\n> > just dangerous to _leave_ without referencing your new commits.\n> \n> Hmm, how about adding a checkbox:\n> \n> [ ] Do not ask again\n> \n> In my experience anything other than a popup will be overseen so I would\n> suggest doing it at least once to prepare the user for the possible\n> consequences.\n\nYeah, that's much better IMHO because at least clueful people can\ndismiss it after the first time.\n\n> IMO such a message is a good thing for the GUI regardless whether we\n> implement the leaving detached HEAD state warning. First I think a\n> typical GUI user does not commit on a detached head that often since\n> there is currently no way to use these commits from the GUI (e.g.\n> format-patch, rebase, ...).\n\nFair enough. I really have no idea what sorts of things gui users do, or\nhow they perceive the system.\n\n> Second because a detached head is very practical for testing work on a\n> remote branch the message box would remind most users to switch to\n> their development branch first. If they only get that message after a\n> series of commits it might become a hassle for them to get these\n> commits onto another branch (remember no format-patch or rebase\n> currently).\n\nGood point.\n\n> > I do think a pop-up is appropriate when you try to check something else\n> > out, and commits you have made on the detached HEAD are about to become\n> > unreferenced. But this is something even the CLI doesn't do, so it would\n> > make sense to see how the check is implemented there first before doing\n> > anything in git-gui.\n> \n> From what I read in this thread it currently seems to be not so easy to\n> precisely find out whether some commit is referenced. (If we care about\n> stuff outside of remotes, heads and tags). But maybe we do not need\n> that for the GUI.\n\nYeah, I think there is still some question about how it should happen,\nand any check in the gui should probably be the same as in the cli. But\nfrom the rest of what you say, that shouldn't impact whether a\nper-commit warning is worth doing.\n\n-Peff\n"},{"id":"161260","messageId":"20110216035032.GB2414@sigill.intra.peff.net","threadId":"26479","inReplyTo":"87pqqtaxke.fsf@fox.patthoyts.tk","subject":"Re: [PATCH] git-gui: give more advice when detaching HEAD","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-16T03:50:32Z","receivedAt":"2011-02-16T03:50:32Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 15, 2011 at 07:48:33PM +0000, Pat Thoyts wrote:\n\n> My feeling is that the user should be making a branch to hold his\n> commits. So I suggest adding some text to suggest that a branch be\n> created and keep annoying the user every time they commit to a detached\n> head. This errs on the side of not dropping commits into the reflog\n> which seems the most useful strategy to me.\n\nI like Heiko's suggestion of a check-box to turn off\ngui.warndetachedcommit, though I personally don't care much as a non-gui\nuser. I also think if you are going to suggest making a branch that\nthere should be an \"OK, make the branch now\" button, or at least a\nbutton to take you to the right dialog to create it. But again, I know\nnothing about gui design and as a non-user I don't have a strong\nfeeling.\n\nBut...\n\n> +\tif {$is_detached && $repo_config(gui.warndetachedcommit)} {\n> +\t\tset msg [mc \"You are about to commit on a detached head.\\\n> +This is a potentially dangerous thing to do because if you switch\\\n> +to another branch you will loose your changes and it can be difficult\\\n> +to retrieve them later from the reflog. You should probably cancel this\\\n> +commit and create a new branch to continue.\\n\\\n\nI do have a strong feeling about English grammar, and this should be\ns/loose/lose/. :)\n\n-Peff\n"},{"id":"161307","messageId":"4D5BF715.40502@terreactive.ch","threadId":"26479","inReplyTo":"5828845.77740.1297797387140.JavaMail.trustmail@mail1.terreactive.ch","subject":"Re: [PATCH] git-gui: give more advice when detaching HEAD","fromName":"Victor Engmark","fromEmail":"victor.engmark@terreactive.ch","sentAt":"2011-02-16T16:11:01Z","receivedAt":"2011-02-16T16:11:01Z","isPatch":true,"sender":{"key":"victor.engmark@terreactive.ch","avatar":null},"body":"On 02/15/2011 08:16 PM, Heiko Voigt wrote:\n> Hi,\n> \n> On Tue, Feb 15, 2011 at 01:39:03AM -0500, Jeff King wrote:\n>> On Sun, Feb 13, 2011 at 01:31:52PM +0100, Heiko Voigt wrote:\n>>\n>>> On Sat, Feb 12, 2011 at 02:05:38AM -0500, Jeff King wrote:\n>>>> 1. Give some indication or warning during commit that you're in a\n>>>> detached state. The CLI template says \"You are not on any branch\"\n>>>> when editing the commit message, and mentions \"detached HEAD\" as\n>>>> the branch in the post-commit summary. As far as I can tell,\n>>>> git-gui says nothing at all.\n>>>\n>>> How about something like this:\n>>> [...]\n>>> Subject: [PATCH] git-gui: warn when trying to commit on a detached head\n>>>\n>>> The commandline is already warning when checking out a detached head.\n>>> Since the only thing thats potentially dangerous is to create commits\n>>> on a detached head lets warn in case the user is about to do that.\n>>\n>> It seems a little heavy-handed to have a dialog pop up for each commit.\n>> It's not actually dangerous to create a commit on a detached HEAD; it's\n>> just dangerous to _leave_ without referencing your new commits.\n> \n> Hmm, how about adding a checkbox:\n> \n> [ ] Do not ask again\n> \n> In my experience anything other than a popup will be overseen so I would\n> suggest doing it at least once to prepare the user for the possible\n> consequences.\n\nThat would be useful. However, there is only so much space in a dialog\nbox (and only so much users will read in one), so to make sure users\nunderstand what is going on (and perhaps advocate some self-learning)\nthere should be a link to more information.\n\n2c,\n-- \nVictor\n"},{"id":"161431","messageId":"20110217172720.GA91738@book.hvoigt.net","threadId":"26479","inReplyTo":"20110216034606.GA2414@sigill.intra.peff.net","subject":"Re: Re: Re: [PATCH] git-gui: give more advice when detaching HEAD","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-02-17T17:27:21Z","receivedAt":"2011-02-17T17:27:21Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Tue, Feb 15, 2011 at 10:46:06PM -0500, Jeff King wrote:\n> On Tue, Feb 15, 2011 at 08:16:21PM +0100, Heiko Voigt wrote:\n> \n> > > It seems a little heavy-handed to have a dialog pop up for each commit.\n> > > It's not actually dangerous to create a commit on a detached HEAD; it's\n> > > just dangerous to _leave_ without referencing your new commits.\n> > \n> > Hmm, how about adding a checkbox:\n> > \n> > [ ] Do not ask again\n> > \n> > In my experience anything other than a popup will be overseen so I would\n> > suggest doing it at least once to prepare the user for the possible\n> > consequences.\n> \n> Yeah, that's much better IMHO because at least clueful people can\n> dismiss it after the first time.\n\nI tried to implement such a dialog yesterday. Unfortunately my tcl/tk\nfu seems not sufficient enough. I managed to create the dialog but did\nnot get the results which button was clicked. It has something to do\nwith the scope of variables in tcl. Pat you would probably be able to\nfix this. I can send you the code if you are interested?\n\n> > > I do think a pop-up is appropriate when you try to check something else\n> > > out, and commits you have made on the detached HEAD are about to become\n> > > unreferenced. But this is something even the CLI doesn't do, so it would\n> > > make sense to see how the check is implemented there first before doing\n> > > anything in git-gui.\n> > \n> > From what I read in this thread it currently seems to be not so easy to\n> > precisely find out whether some commit is referenced. (If we care about\n> > stuff outside of remotes, heads and tags). But maybe we do not need\n> > that for the GUI.\n> \n> Yeah, I think there is still some question about how it should happen,\n> and any check in the gui should probably be the same as in the cli. But\n> from the rest of what you say, that shouldn't impact whether a\n> per-commit warning is worth doing.\n\nWill someone be working on this? Otherwise: Implementing the previously\nsuggested solution is quite straightforward for git-gui. I could\nimplement that check in git-gui first and once the CLI has some\nmechanism for this check we could switch to that.\n\nCheers Heiko\n"},{"id":"161432","messageId":"20110217173851.GB91738@book.hvoigt.net","threadId":"26479","inReplyTo":"87pqqtaxke.fsf@fox.patthoyts.tk","subject":"Re: Re: [PATCH] git-gui: give more advice when detaching HEAD","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-02-17T17:38:51Z","receivedAt":"2011-02-17T17:38:51Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Tue, Feb 15, 2011 at 07:48:33PM +0000, Pat Thoyts wrote:\n> From: Heiko Voigt \n> Date: Tue, 15 Feb 2011 19:43:54 +0000\n> Subject: [PATCH] git-gui: warn when trying to commit on a detached head\n> \n> The commandline is already warning when checking out a detached head.\n> Since the only thing thats potentially dangerous is to create commits\n> on a detached head lets warn in case the user is about to do that.\n> \n> Signed-off-by: Heiko Voigt \n> Signed-off-by: Pat Thoyts \n> ---\n[...]\n> My feeling is that the user should be making a branch to hold his\n> commits. So I suggest adding some text to suggest that a branch be\n> created and keep annoying the user every time they commit to a detached\n> head. This errs on the side of not dropping commits into the reflog\n> which seems the most useful strategy to me.\n> \n> So here is a modded version of Heiko's patch.\n\nThanks for cleaning up my wording. I would be fine with this patch.\nI played with creating a dialog including a checkbox yesterday. Please\nsee my other answer to this thread whether we work on this further.\nOtherwise I would be fine with just issuing the warning every time. Its\nbetter than not warning at all and using the configuration option a\nclueful person can still disable the warning.\n\nCheers Heiko\n\nP.S.: Should I prepare a separate patch to document the variable for\n Junio once he pulls again from you?\n"},{"id":"161468","messageId":"7vvd0i8dbc.fsf@alter.siamese.dyndns.org","threadId":"26479","inReplyTo":"20110212082108.GA19656@sigill.intra.peff.net","subject":"Re: [PATCH] git-gui: give more advice when detaching HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-17T23:13:27Z","receivedAt":"2011-02-17T23:13:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Want to do a proof-of-concept patch? Then we can get some real timings.\n\nThis was about \n\n> > 2. When leaving the detached state, notice that we have commits not\n> > contained in any other ref and pop up an \"are you sure you want to\n> > lose these commits\" dialog, with an option to create a branch. This\n> > is something we considered and rejected for the CLI, but I wonder\n> > if it makes more sense for git-gui.\n\nI thought about counting remaining commits, but decided against it. The\ncost has already paid (the \"limited\" traversal already has happend), so it\nmay not be too bad to show each of them in oneline format if somebody\nreally wanted to to tell the user \"here are the stuff you are about to\nlose\".\n\nAlso it might make sense to have a training wheel option of forcing\n\"checkout -f branch-I-wanted-to-go\" in this case as an extra safety valve,\nand it would be even Ok to enable the training wheel by default, as long\nas annoyed experts can turn it off via configuration.\n\n builtin/checkout.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++----\n 1 files changed, 60 insertions(+), 6 deletions(-)\n\ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex cd7f56e..1f5376f 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -503,6 +503,17 @@ static void detach_advice(const char *old_path, const char *new_name)\n \tfprintf(stderr, fmt, new_name);\n }\n \n+static void suggest_reattach(struct commit *commit)\n+{\n+\tconst char fmt[] =\n+\t\"Note: you are about to abandon commit %1$s\\n\\n\"\n+\t\"None of your branches nor tags refer to this commit. If you want to\\n\"\n+\t\"keep this commit, you can do so by creating a new branch. Example:\\n\\n\"\n+\t\" git branch new_branch_name %1$s\\n\\n\";\n+\n+\tfprintf(stderr, fmt, sha1_to_hex(commit->object.sha1));\n+}\n+\n static void update_refs_for_switch(struct checkout_opts *opts,\n \t\t\t\t struct branch_info *old,\n \t\t\t\t struct branch_info *new)\n@@ -578,6 +589,54 @@ static void update_refs_for_switch(struct checkout_opts *opts,\n \t\treport_tracking(new);\n }\n \n+struct rev_list_args {\n+\tint argc;\n+\tint alloc;\n+\tconst char **argv;\n+};\n+\n+static void add_one_rev_list_arg(struct rev_list_args *args, const char *s)\n+{\n+\tALLOC_GROW(args->argv, args->argc + 1, args->alloc);\n+\targs->argv[args->argc++] = s;\n+}\n+\n+static int add_one_ref_to_rev_list_arg(const char *refname,\n+\t\t\t\t const unsigned char *sha1,\n+\t\t\t\t int flags,\n+\t\t\t\t void *cb_data)\n+{\n+\tadd_one_rev_list_arg(cb_data, refname);\n+\treturn 0;\n+}\n+\n+/*\n+ * We are about to leave commit that was at the tip of a detached\n+ * HEAD. If it is not reachable from any ref, this is the last chance\n+ * for the user to do so without resorting to reflog.\n+ */\n+static void orphaned_commit_warning(struct commit *commit)\n+{\n+\tstruct rev_list_args args = { 0, 0, NULL };\n+\tstruct rev_info revs;\n+\n+\tadd_one_rev_list_arg(&args, \"(internal)\");\n+\tadd_one_rev_list_arg(&args, sha1_to_hex(commit->object.sha1));\n+\tadd_one_rev_list_arg(&args, \"--not\");\n+\tfor_each_ref(add_one_ref_to_rev_list_arg, &args);\n+\tadd_one_rev_list_arg(&args, \"--\");\n+\tadd_one_rev_list_arg(&args, NULL);\n+\n+\tinit_revisions(&revs, NULL);\n+\tif (setup_revisions(args.argc - 1, args.argv, &revs, NULL) != 1)\n+\t\tdie(\"internal error: only -- alone should have been left\");\n+\tif (prepare_revision_walk(&revs))\n+\t\tdie(\"internal error in revision walk\");\n+\tif (!(commit->object.flags & UNINTERESTING))\n+\t\tsuggest_reattach(commit);\n+\tdescribe_detached_head(\"Previous HEAD position was\", commit);\n+}\n+\n static int switch_branches(struct checkout_opts *opts, struct branch_info *new)\n {\n \tint ret = 0;\n@@ -605,13 +664,8 @@ static int switch_branches(struct checkout_opts *opts, struct branch_info *new)\n \tif (ret)\n \t\treturn ret;\n \n-\t/*\n-\t * If we were on a detached HEAD, but have now moved to\n-\t * a new commit, we want to mention the old commit once more\n-\t * to remind the user that it might be lost.\n-\t */\n \tif (!opts->quiet && !old.path && old.commit && new->commit != old.commit)\n-\t\tdescribe_detached_head(\"Previous HEAD position was\", old.commit);\n+\t\torphaned_commit_warning(old.commit);\n \n \tupdate_refs_for_switch(opts, &old, new);\n \n"}]}