On Thu, 2024-01-18 at 14:29 +0100, Patrick Steinhardt wrote: > On Thu, Jan 18, 2024 at 03:53:21PM +0300, Konstantin Kharlamov wrote: > > (please keep me CC'ed, I'm not subscribed) > > > > Hello! > > > > There's a well-known problem of git not fully checking out changes > > while doing e.g. `git checkout` and similar commands when you have > > submodules. So e.g. if HEAD changes a submodule commit and you do > > an > > interactive rebase to HEAD~2, you may be lucky to find a submodule > > commit change in `git diff` (because if you don't get lucky, you > > won't > > notice that and commit the change to the unrelated HEAD~2). > > > > As a workaround I have a `git submodule update` inside `post- > > checkout` > > hook. > > > > Now, the problem is I still often finding myself having the wrong > > submodule ID, and I tracked down that problem to commands such as > > `am/rebase/cherry-pick --abort` also not updating the submodule, > > nor > > executing `post-checkout`. > > > > I looked through `man githooks` but couldn't find any way to > > execute a > > `git submodule update` during these aborts. > > > > Any ideas how to fix these? > > Are you aware of the `submodule.recurse` config? If set, it should > cause > git-checkout(1) and many other commands to recurse into submodules > and > update them accordingly. This should both make your post-checkout > hook > obsolete and should also work with git-cherry-pick(1) et al. It doesn't seem to work ☹ I've set it, and now supposed my top commit changes submodule. So I do a `git rebase -i HEAD~2` and "reword" the previous commit. After "reword"ing is done, git returns me back to HEAD commit and when I execute `git diff` I see the submodule ID changed ☹
