{"thread":{"id":"52759","subject":"fatal: cannot rebase with locally recorded submodule modifications","startedAt":"2020-02-07T20:50:33Z","lastAt":"2020-11-14T00:32:30Z","messageCount":4,"participants":["Brice Goglin","Shourya Shukla","Philippe Blain"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"391352","messageId":"660c39af-d0f2-5e4c-66a0-5c78b646b023@free.fr","threadId":"52759","inReplyTo":null,"subject":"fatal: cannot rebase with locally recorded submodule modifications","fromName":"Brice Goglin","fromEmail":"bgoglin@free.fr","sentAt":"2020-02-07T20:50:29Z","receivedAt":"2020-02-07T20:50:33Z","isPatch":false,"sender":{"key":"bgoglin@free.fr","avatar":null},"body":"Hello\n\nI don't understand why git pull --rebase --recurse-submodules fails after a git reset --hard\nto the previous commit. I didn't touch the submodule, it's supposed to be clean:\n\n$ git clone --recursive git@github.com:open-mpi/ompi.git\n[...]\n$ git reset --hard HEAD^\nHEAD is now at 395e2c9d8f Merge pull request #7364 from awlauria/fix_compile\n$ git pull --rebase --recurse-submodules\nFetching submodule opal/mca/hwloc/hwloc2/hwloc\nfatal: cannot rebase with locally recorded submodule modifications\n\nWhy is failing here?\n\n$ git submodule status\n 38433c0f5fae0b761bd20e7b928c77f3ff2e76dc opal/mca/hwloc/hwloc2/hwloc (hwloc-2.1.0rc2-33-g38433c0f)\n(that's expected)\n\n$ git status\nHEAD detached at 38433c0f\nnothing to commit, working tree clean\n\nThanks\n\nBrice\n\n"},{"id":"391355","messageId":"20200207220403.28961-1-shouryashukla.oo@gmail.com","threadId":"52759","inReplyTo":"660c39af-d0f2-5e4c-66a0-5c78b646b023@free.fr","subject":"Re: fatal: cannot rebase with locally recorded submodule modifications","fromName":"Shourya Shukla","fromEmail":"shouryashukla.oo@gmail.com","sentAt":"2020-02-07T22:04:03Z","receivedAt":"2020-02-07T22:04:25Z","isPatch":false,"sender":{"key":"shouryashukla.oo@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43680618?v=4"},"body":"Hello Brice,\n\nThe error you are facing here is actually a bug in the\n'git pull' command[1]. When one tries to use the\n'--recurse-submodules' tag with the command, it tends to fail.\n\n> Why is failing here?\n\nGoing into a bit detail of 'git pull', the command actually\nis a combination of 'git fetch' and 'git merge'(unless any\nother tag is specified i.e. 'rebase' here which would mean\na fetch followed by a rebase). Quoting from the documentation:\n\n> Using --recurse-submodules can only fetch new commits in already\nchecked out submodules right now\n\nUsing the '--recurse-submodules' tag will try merging/rebasing any\nchanges(updations, additions, deletions, etc.) made to the fetched\nsubmodule(s) from upstream, i.e. the _un-checked out_ submodules into\nour local repository which will cause the error to be thrown as it is\nnot supported right now. This will therefore create the detached HEAD\njust like the one you obtained.\n\nThe \"workaround\" is to do a 'git fetch' and then merge again after the\n'git pull <tag> --recurse-submodules'.\n\nThe presence/absence of 'git reset --hard' before the pull  won't create\nany difference to this error in my opinion.\n\nRegards,\nShourya Shukla\n\n[1]: https://git-scm.com/docs/git-pull#_bugs\n\n"},{"id":"409935","messageId":"20D6104D-CA02-4CE4-A1C0-2F9386DEDA3B@gmail.com","threadId":"52759","inReplyTo":"660c39af-d0f2-5e4c-66a0-5c78b646b023@free.fr","subject":"Re: fatal: cannot rebase with locally recorded submodule modifications","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2020-11-13T23:47:03Z","receivedAt":"2020-11-13T23:47:19Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Brice,\n\n> Le 7 févr. 2020 à 15:50, Brice Goglin <bgoglin@free.fr> a écrit :\n> \n> Hello\n> \n> I don't understand why git pull --rebase --recurse-submodules fails after a git reset --hard\n> to the previous commit. I didn't touch the submodule, it's supposed to be clean:\n> \n> $ git clone --recursive git@github.com:open-mpi/ompi.git\n> [...]\n> $ git reset --hard HEAD^\n> HEAD is now at 395e2c9d8f Merge pull request #7364 from awlauria/fix_compile\n> $ git pull --rebase --recurse-submodules\n> Fetching submodule opal/mca/hwloc/hwloc2/hwloc\n> fatal: cannot rebase with locally recorded submodule modifications\n> \n> Why is failing here?\n\nIt's failing because there is a bug in the code for 'git pull --rebase --recurse-submodules'\nwhen the current branch and its remote-tracking counterpart have no fork-point,\nwhich seem to be the situation happening here.\n\nI've just finished a patch series that fixes this bug. You can take a look at it here:\nhttps://github.com/gitgitgadget/git/pull/789. I will send it to the list shortly, and will\nCC you when I do.\n\nCheers,\n\nPhilippe."},{"id":"409939","messageId":"3D5F0B08-A4A1-4891-895F-54A4A437BDB2@gmail.com","threadId":"52759","inReplyTo":"20200207220403.28961-1-shouryashukla.oo@gmail.com","subject":"Re: fatal: cannot rebase with locally recorded submodule modifications","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2020-11-14T00:32:17Z","receivedAt":"2020-11-14T00:32:30Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Shourya,\n\n> Le 7 févr. 2020 à 17:04, Shourya Shukla <shouryashukla.oo@gmail.com> a écrit :\n> \n> Hello Brice,\n> \n> The error you are facing here is actually a bug in the\n> 'git pull' command[1]. When one tries to use the\n> '--recurse-submodules' tag with the command, it tends to fail.\n\nLet's not discourage our users ;) It is untrue that it tends to fail.\n\n>> Why is failing here?\n> \n> Going into a bit detail of 'git pull', the command actually\n> is a combination of 'git fetch' and 'git merge'(unless any\n> other tag is specified i.e. 'rebase' here which would mean\n> a fetch followed by a rebase). Quoting from the documentation:\n> \n>> Using --recurse-submodules can only fetch new commits in already\n> checked out submodules right now\n> \n> Using the '--recurse-submodules' tag will try merging/rebasing any\n> changes(updations, additions, deletions, etc.) made to the fetched\n> submodule(s) from upstream, i.e. the _un-checked out_ submodules into\n> our local repository which will cause the error to be thrown as it is\n> not supported right now.\n\nThat part of the doc talks about the fact that when using '--recurse-submodules', only commits\nin already checked out submodules (\"populated submodules\" is the wording used in the docs \nfor that option) will be *fetched*. If you take a look at, for example,\n\n    git blame -L 240,+10 Documentation/git-pull.txt\n\nyou'll see that this section was added in 794a3592ad (fetch/pull: Describe \n--recurse-submodule restrictions in the BUGS section, 2011-03-06), when 'git fetch'\nlearned the '--recurse-submodules' flag. At the time 'git pull --recurse-submodules' \ndid *not* update the working tree of the submodules, it just passed '--recurse-submodules' \nto the underlying 'git fetch'. 'git pull' learned to update the working tree of the submodules\n(and also rebase the submodules themselves under very specific circumstances) in \na6d7eb2c7a (pull: optionally rebase submodules (remote submodule changes only), \n2017-06-23). \n\nSo this \"bug\" you mention is not what is happening here. Since Brice clone with \n'--recurse-submodules', all submodules will be cloned, initialized and populated as \npart of the superproject clone, so they are all already checked out when 'git pull' is invoked.\n\nAlso, the \"Bugs\" section in the docs that you refer to does not talk about the command\nerroring; it just describes a limitation of 'git fetch --recurse-submodules'. And as a side note,\nthere is no test in the test suite that checks this behaviour (looking at t5526-fetch-submodules.sh\nand t5572-pull-submodule.sh). It would be good to fix that by adding a couple 'test_expect_failure' \ntests, or even to fix the behaviour itself. \n\nNote also that when this \"Bugs\" section was added, the submodule repositories \nwere cloned directly in the superproject working tree instead of being cloned to \n.git/modules/<submodule-name>. This explains why this limitation existed at the time:\nyou can't fetch the submodules if there is no filesystem location to put their Git repository!\nA few months later, 501770e1bb (Move git-dir for submodules, 2011-08-15), implemented \nthe \"new-style\" submodule setup, i.e. cloning the submodules repositories inside the Git repository\nof the superproject, as is standard these days. So there is no good reason today to not fix this \nbug, in my opinion.\n\nGoing back to Brice's bug:\n\n> The \"workaround\" is to do a 'git fetch' and then merge again after the\n> 'git pull <tag> --recurse-submodules'.\n\nI don't think there is a workaround until my fixes get merged, apart from\nnot using '--recurse-submodules' with 'git pull --rebase'. Of course then you \nhave to remember to *always* do 'git submodule update --recursive' after \neach pull if you want your submodule checkouts to stay in sync with the commits\nrecorded in the superproject.\n\n> The presence/absence of 'git reset --hard' before the pull  won't create\n> any difference to this error in my opinion.\n\nOn the contrary: as I wrote in my answer to Brice, it is exactly because 'git reset --hard' is used \nhere that the code wrongly errors.\n\nCheers, and thank you for all the work you put in the rewrite of the submodule code\nfrom shell to C this summer.\n\nPhilippe."}]}