{"thread":{"id":"48013","subject":"git submodule update - reset instead of checkout?","startedAt":"2018-03-09T15:07:27Z","lastAt":"2018-03-26T23:33:30Z","messageCount":2,"participants":["Andreas Krey","Stefan Beller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"341343","messageId":"20180309150719.GA30596@inner.h.apk.li","threadId":"48013","inReplyTo":null,"subject":"git submodule update - reset instead of checkout?","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2018-03-09T15:07:19Z","receivedAt":"2018-03-09T15:07:27Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"Hi everyone,\n\nI've been reading up on the current state of git submodules\n(our customer's customers want to use them, causing a slight\ngroan from our customer).\n\nThe usability thing I wonder about - with git submodule update,\nis it necessary to detach the head to the current (or upstream)\nhead, instead of resetting the current branch to that state?\n\nPrimary interest in the question: Seeing 'detached head' scares\nalmost everybody. To brainstorm:\n\n- as we can already use 'submodule update --remote' to update\n  to the remote head of a branch, it would be logical to have\n  that branch checked out locally (and unfortunately, potentially\n  have that branch's name conflict with the remote branch setup).\n\n- when developers more or less accidentally commit on the detached\n  head, all is not lost yet (I remember this being differently),\n  but if the next 'submodule update' just resets again, the commit\n  just made is still dropped, just as in the detached head state.\n\n- So, we'd need to have 'submodule update' act closer to the pull or\n  rebase counterparts and refuse to just lose commits (or uncommitted\n  changes).\n\nHaving a checked-out branch in the submodule would have the advantage\nthat I can 'just' push local commits. At the moment, doing that requires\na relatively intricate dance, not at all similar to working in the\nbase (parent) module.\n\nI'm working on hooks that automatically update the submodules after\na commit change (merge, pull, checkout) in the parent module, but\nwith the additional feature of (a) keeping a branch checked out\nand (b) avoid discarding local changes. Probably means I shouldn't\ninvoke 'submodule update' at all, and deal with everyting myself.\n\nAny thoughs/comments/helpful hints?\n\n(Addional complexity: egit/jgit is in use as well, and the work model\nwe will arrive at probabaly needs to work with the current egit.)\n\n- Andreas\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds <torvalds@*.org>\nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"},{"id":"343090","messageId":"CAGZ79kZ16+ZtcXx45nvcOeT0wSM7TEi8iDoxB6An91d-FanZhg@mail.gmail.com","threadId":"48013","inReplyTo":"20180309150719.GA30596@inner.h.apk.li","subject":"Re: git submodule update - reset instead of checkout?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-03-26T23:33:13Z","receivedAt":"2018-03-26T23:33:30Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Fri, Mar 9, 2018 at 7:07 AM Andreas Krey <a.krey@gmx.de> wrote:\n\n> Hi everyone,\n\n> I've been reading up on the current state of git submodules\n> (our customer's customers want to use them, causing a slight\n> groan from our customer).\n\n> The usability thing I wonder about - with git submodule update,\n> is it necessary to detach the head to the current (or upstream)\n> head, instead of resetting the current branch to that state?\n\nTry \"git checkout --recurse-submodules\" or\n\"git reset --recurse-submodules\"  (there is also the\nsubmodule.recurse option in case you don't want to type\nthe option all the time)\n\n\n> Primary interest in the question: Seeing 'detached head' scares\n> almost everybody. To brainstorm:\n\nI agree on that. That is what we are trying to work out\neventually, too.\n\nOne idea is to \"reattach the submodule branch if it fits\"\nanother idea would be a submodule ref store that is\n(partially) tied to the superproject, such that the HEAD\nof the submodule is non-existent for most of the time.\nhttps://public-inbox.org/git/cover.1512168087.git.jonathantanmy@google.com/\n\n> - as we can already use 'submodule update --remote' to update\n>    to the remote head of a branch, it would be logical to have\n>    that branch checked out locally (and unfortunately, potentially\n>    have that branch's name conflict with the remote branch setup).\n\n> - when developers more or less accidentally commit on the detached\n>    head, all is not lost yet (I remember this being differently),\n>    but if the next 'submodule update' just resets again, the commit\n>    just made is still dropped, just as in the detached head state.\n\n> - So, we'd need to have 'submodule update' act closer to the pull or\n>    rebase counterparts and refuse to just lose commits (or uncommitted\n>    changes).\n\n> Having a checked-out branch in the submodule would have the advantage\n> that I can 'just' push local commits. At the moment, doing that requires\n> a relatively intricate dance, not at all similar to working in the\n> base (parent) module.\n\n> I'm working on hooks that automatically update the submodules after\n> a commit change (merge, pull, checkout) in the parent module, but\n> with the additional feature of (a) keeping a branch checked out\n> and (b) avoid discarding local changes. Probably means I shouldn't\n> invoke 'submodule update' at all, and deal with everyting myself.\n\n> Any thoughs/comments/helpful hints?\n\nOur plan is to deprecate \"git submodule\" just like \"git remote\" is not\na well known tool any more. (e.g. Instead of git remote update, use\ngit fetch, that learned about updating the remote tracking branches\non its own)\n\n\n> (Addional complexity: egit/jgit is in use as well, and the work model\n> we will arrive at probabaly needs to work with the current egit.)\n\nThat sounds familiar, we also have JGit/Gerrit in the setup.\n\nStefan\n"}]}