{"thread":{"id":"6720","subject":"Why are commits on detached heads good, again?","startedAt":"2007-02-07T14:26:42Z","lastAt":"2007-02-07T15:32:19Z","messageCount":3,"participants":["linux@horizon.com","Nicolas Pitre","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"33805","messageId":"20070207142642.23503.qmail@science.horizon.com","threadId":"6720","inReplyTo":null,"subject":"Why are commits on detached heads good, again?","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2007-02-07T14:26:42Z","receivedAt":"2007-02-07T14:26:42Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"I know I made the case for the value of detached heads in a read-only\nmode. Why should I need to think up a branch name to look at v2.6.18?\nI *have* a name; it's v2.6.18.\n\nAnd it got implemented. But some people said \"Hey! Let's allow\ncommits on top of detached heads, too!\" Whish has led to a huge thread\nabout handling the resultant potential confusion.\n\nI agree 100% that it's entirely doable and can be used safely.\n\nBut perhaps the confusion is more trouble than it's worth? If the rules\nare hard to implement, is that perhaps a clue that they're hard for the\npoor user to understand?\n\nI'd like to agitate for forbidding commits on detached heads as a\nsimplicity issue. If I'm going to ask git to *remember* some work for\nme, is it terribly unreasonable for me to have to think of a name for it?\nI can name it \"temp\" or \"foo\" or \"test\" or \"hackhack\" or \"x\" if I want.\n\nRemember, we've survived fine up to now when you can't even *look* at an\nold commit without coming up with a name for it (or using git-tar-tree,\nor some other tool). And the pressure to change hasn't been *that*\nstrong.\n\nEven if it's slightly more stringent than required, why not say\n\"you're not allowed to commit when you're not on a branch; think\nof a name for your work and do 'git checkout -b first'\"?\n\nIs it that onerous? It has the great virtue of being very simple\nto explain and remember. \"If you committed without being on a branch,\nyou're not allowed to switch away until you give that branch a name,\nor you accept losing the data\" is a lot more complicated.\n(Never mind the arguing about the reflog and ORIG_HEAD.)\n\nPeople are used to the idea that if you want to save your work, you need\nto think up a file name. Postponing that time until you switch away\nfrom the HEAD doesn't actually save any work unless you throw away the\ncommits, and presumably that's a rare and unusual situation.\n(And the extra work is trivial compared to the effort writing\nthe commits you're discarding.)\n\n\nCan someone explain why committing on top of a detached head is a\nkiller feature and thinking up a name sooner rather than later is\na huge inconvenience?\n\nAs someone trying to document all this, it would certainly make my\nlife easier to just forbid it. I can just say:\n\ngit-checkout: You may check out any commit you like.\n\tHowever, if the name you specify is in the .git/refs/heads\n\tdirectory, you are \"on that branch\" and can commit to it.\n\tIf you specify the same commit by a tag or raw SHA ID,\n\tand do not give a name with \"git checkout -b \", you\n\tare not on any branch, and a later git-commit will fail.\ngit-commit: If the last thing you checked out with \"git-checkout\"\n\t(with no pathname arguments) was a branch (in .git/refs/heads),\n\tthe commit is made and the head is automatically updated to\n\tpoint to the new head.\n\tIf you have checked out a \"bare commit\", git-commit will refuse\n\tto make the commit because it has nowhere to record it.\n\tYou can \"git checkout -b \" to create a new branch\n\tstarting from the current HEAD. This will not alter the\n\tcontents of the index or the working directory.\n\n\nI'm willing to be convinced, but could someone please explain the\nvirtues of committing to a detached HEAD that outweigh the virtue\nof simplicity?\n"},{"id":"33808","messageId":"Pine.LNX.4.64.0702070954110.13009@xanadu.home","threadId":"6720","inReplyTo":"20070207142642.23503.qmail@science.horizon.com","subject":"Re: Why are commits on detached heads good, again?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-07T14:56:29Z","receivedAt":"2007-02-07T14:56:29Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 7 Feb 2007, linux@horizon.com wrote:\n\n> I agree 100% that it's entirely doable and can be used safely.\n> \n> But perhaps the confusion is more trouble than it's worth? If the rules\n> are hard to implement, is that perhaps a clue that they're hard for the\n> poor user to understand?\n\nThe rules are simple and have been implemented now and the confusion is \nno more.\n\n\nNicolas\n"},{"id":"33813","messageId":"Pine.LNX.4.63.0702071629210.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6720","inReplyTo":"20070207142642.23503.qmail@science.horizon.com","subject":"Re: Why are commits on detached heads good, again?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-07T15:32:19Z","receivedAt":"2007-02-07T15:32:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 7 Feb 2007, linux@horizon.com wrote:\n\n> Can someone explain why committing on top of a detached head is a killer \n> feature and thinking up a name sooner rather than later is a huge \n> inconvenience?\n\nI agree that \"because I could\" is a weak excuse for this feature.\n\nBut actually, I think it is more convenient to be able to play around with \nan idea, properly committing simple steps, and finally, if, and only if, \nit works as expected, make a topic branch of it.\n\nIOW:\n\ncheckout v2.6.20\n\ncommit\n\ncommit\n