{"thread":{"id":"18645","subject":"Detached HEAD warning (again)","startedAt":"2009-03-30T16:09:12Z","lastAt":"2009-04-01T20:41:49Z","messageCount":4,"participants":["Pieter de Bie","Johannes Schindelin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"109922","messageId":"9099EAF5-6B43-4F15-A905-9E21B45B7AE9@ai.rug.nl","threadId":"18645","inReplyTo":null,"subject":"Detached HEAD warning (again)","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2009-03-30T16:09:12Z","receivedAt":"2009-03-30T16:09:12Z","isPatch":false,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"Hi all,\n\nI strongly remember there being a discussion about this a few weeks  \nago, but I\ncan't find it. Basically, someone wanted to introduce a warning every  \ntime\nsomeone commits on a detached HEAD. This was shot down because there  \nalready\nis a big warning when you detach your HEAD (with which I agree).\n\nHowever, someone here: http://news.ycombinator.com/item?id=538619  \npointed to\nan example here: http://book.git-scm.com/5_submodules.html , which  \nworks with\nsubmodules:\n\n\t$ git submodule update --init\n\t# sub/ is created\n\t$ (cd sub && touch a && git add a && git commit -am \"Add new file\")\n\t[detached HEAD 8641889] Add new file\n\t 0 files changed, 0 insertions(+), 0 deletions(-)\n\t create mode 100644 a\n\n\t$ git submodule update\n\t$ ls sub/a\n\tls: sub/a: No such file or directory\n\nNow, it DOES say 'detached HEAD', but I still think this is something  \neasily\nmissed and something that can cause a lot of confusion. Perhaps a  \nwarning in\nsuch cases wouldn't hurt?\n\n- Pieter\n"},{"id":"109994","messageId":"alpine.DEB.1.00.0903311203490.10279@pacific.mpi-cbg.de","threadId":"18645","inReplyTo":"9099EAF5-6B43-4F15-A905-9E21B45B7AE9@ai.rug.nl","subject":"Re: Detached HEAD warning (again)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-31T10:04:27Z","receivedAt":"2009-03-31T10:04:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 30 Mar 2009, Pieter de Bie wrote:\n\n> I strongly remember there being a discussion about this a few weeks ago, \n> but I can't find it. Basically, someone wanted to introduce a warning \n> every time someone commits on a detached HEAD. This was shot down \n> because there already is a big warning when you detach your HEAD (with \n> which I agree).\n> \n> However, someone here: http://news.ycombinator.com/item?id=538619 \n> pointed to an example here: http://book.git-scm.com/5_submodules.html , \n> which works with submodules:\n> \n> \t$ git submodule update --init\n> \t# sub/ is created\n> \t$ (cd sub && touch a && git add a && git commit -am \"Add new file\")\n> \t[detached HEAD 8641889] Add new file\n> \t 0 files changed, 0 insertions(+), 0 deletions(-)\n> \t create mode 100644 a\n> \n> \t$ git submodule update\n> \t$ ls sub/a\n> \tls: sub/a: No such file or directory\n\n\t$ cd sub\n\t$ git checkout HEAD@{1}\n\nCiao,\nDscho\n"},{"id":"110043","messageId":"D561809D-BEE9-417A-B030-8337533C8E53@ai.rug.nl","threadId":"18645","inReplyTo":"alpine.DEB.1.00.0903311203490.10279@pacific.mpi-cbg.de","subject":"Re: Detached HEAD warning (again)","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2009-03-31T17:59:38Z","receivedAt":"2009-03-31T17:59:38Z","isPatch":false,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"\nOn Mar 31, 2009, at 11:04 AM, Johannes Schindelin wrote:\n\n>> \t$ git submodule update --init\n>> \t# sub/ is created\n>> \t$ (cd sub && touch a && git add a && git commit -am \"Add new file\")\n>> \t[detached HEAD 8641889] Add new file\n>> \t 0 files changed, 0 insertions(+), 0 deletions(-)\n>> \t create mode 100644 a\n>>\n>> \t$ git submodule update\n>> \t$ ls sub/a\n>> \tls: sub/a: No such file or directory\n>\n> \t$ cd sub\n> \t$ git checkout HEAD@{1}\n\nYes, I know that the commits can still be recovered\n(otherwise this would be a much bigger issue), but 'git\nreflog' has never been a necessary part of a workflow, has\nit? It's nifty and can be very useful in situations where you\naccidentally lost something, but you can hardly call this a\nnice workflow or expect people that use submodules to know\nabout this.\n\n- Pieter\n"},{"id":"110165","messageId":"7vr60ct8c2.fsf@gitster.siamese.dyndns.org","threadId":"18645","inReplyTo":"9099EAF5-6B43-4F15-A905-9E21B45B7AE9@ai.rug.nl","subject":"Re: Detached HEAD warning (again)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-01T20:41:49Z","receivedAt":"2009-04-01T20:41:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pieter de Bie <pdebie@ai.rug.nl> writes:\n\n> I strongly remember there being a discussion about this a few weeks ago,\n> but I can't find it. Basically, someone wanted to introduce a warning\n> every time someone commits on a detached HEAD. This was shot down\n> because there already is a big warning when you detach your HEAD (with\n> which I agree).\n>\n> However, someone here: http://news.ycombinator.com/item?id=538619\n> pointed to an example here: http://book.git-scm.com/5_submodules.html ,\n> which works with submodules:\n>\n> \t$ git submodule update --init\n> \t# sub/ is created\n> \t$ (cd sub && touch a && git add a && git commit -am \"Add new file\")\n> \t[detached HEAD 8641889] Add new file\n> \t 0 files changed, 0 insertions(+), 0 deletions(-)\n> \t create mode 100644 a\n>\n> \t$ git submodule update\n> \t$ ls sub/a\n> \tls: sub/a: No such file or directory\n>\n> Now, it DOES say 'detached HEAD', but I still think this is something\n> easily missed and something that can cause a lot of confusion. Perhaps a\n> warning in such cases wouldn't hurt?\n\nThere are two distinct uses of detached HEAD state.\n\n * Sight-see.  Jump around in various points in history in order to check\n   the contents inside work tree.  \"git checkout vX.Y.Z\" tag to build the\n   released version and running bisect are examples of such uses.\n\n * Rebuilding history outside of any branch.  You could:\n\n\t... on \"topic\" that is to be rewritten ... \n\t$ git checkout -b topic-2\n        $ git rebase -i master\n\t... check the result, compare it with the original ...\n\t$ git show-branch topic topic-2\n        $ git diff topic topic-2\n\t... wrap it up ...\n        $ git branch -f topic\n        $ git checkout topic\n        $ git branch -D topic-2\n\n   but it often is more convenient to detach the HEAD at the fork point of\n   it:\n\n\t$ git checkout topic^0\n        $ git rebase -i master\n        $ git show-branch topic HEAD\n        $ git diff topic HEAD\n        $ git branch -f topic\n        $ git checkout topic\n\nWhen switching branches between superproject branches that have different\ncommits at one submodule, you may need to have a checkout of the matching\ncommit in the submodule directory.  From the superproject's point of view,\na submodule is not something you are developing directly (you may debug\nand perform other observation of what is in submodule) inside its context,\niow inside the superproject's checkout.  A submodule is a shared resource\namong multiple superprojects, does not belong to a particular\nsuperproject, and inside one particular superproject's context is not the\nbest place to be developing it.  In such a workflow, the submodule\ncheckout is used only in \"sightseeing\" mode, and the user should not even\nbe thinking about making commits in there to affect the submodule's\nhistory.  There is no need for a huge warning.\n\n\tSide note.  In such a workflow, when you find issues in submodule\n\tinside the context of the superproject checkout, you address them\n\tthere first, perhaps by even making commits, but then you take the\n\tchanges back to a standalone checkout the submodule repository you\n\tkeep elsewhere (perhaps you would pull and may even need to\n\tmerge), independently validate the result, perhaps within the\n\tcontext of some other superproject that shares the submodule,\n\tbefore advancing the branch tip.  And then you fetch the result\n\tback to the submodule checkout you started from.\n\nThings get complex _only_ when you start using the submodule checkout that\nis contained within a superproject work tree as the primary place to\nadvance history of the submodule.  Otherwise, your submodule \"repository\"\nembedded within the superproject checkout do not even have to have any\nbranch.  Its HEAD can always be detached.\n\nA few random thoughts to reduce the need of detached HEAD in the submodule\ncontext, if the user chooses to use it to develop history:\n\n * Perhaps \"git submodule update\" may want an optional parameter for the\n   users to tell \"update by switching to this branch in the submodule\",\n   instead of detaching HEAD?  The submodule checkout may or may not what\n   the superproject records for the path as the result, but after that an\n   add followed by a commit in the superproject will record the fact that\n   you now want to bind a new commit at the tip of the submoudle branch to\n   the submodule path.\n\n * Perhaps \"git submodule\" may want to learn a feature for the users to\n   optinally express \"In my workflow, when I am on superproject branch\n   'xyzzy', I want branch 'frotz' in this submodule\" to facilitate the\n   above?\n\n * When we switch branches while you have local changes to a blob in your\n   work tree, you take them with you if two branches record the same blob\n   at the path, and need to force a merge if two branches record different\n   blobs.  In a similar way, perhaps when the commit recorded in the\n   superproject tree does not match what the tip of the submodule branch\n   switched to with the new feature suggested above, \"submodule update\"\n   can fail and give the user a chance to force a merge?\n"}]}