On Wed, Sep 28, 2022 at 04:07:40PM +0100, Peter Maydell wrote: > On Wed, 28 Sept 2022 at 15:29, Michael S. Tsirkin <m...@redhat.com> wrote: > > > > On Wed, Sep 28, 2022 at 11:18:18AM +0100, Daniel P. Berrangé wrote: > > > On Wed, Sep 28, 2022 at 06:13:45AM -0400, Michael S. Tsirkin wrote: > > > > On Wed, Sep 28, 2022 at 10:37:14AM +0100, Daniel P. Berrangé wrote: > > > > > There's also the perenial problem that developers frequently send > > > > > patches that mistakenly include submodule changes, which is related > > > > > to the > > > > > way that 'git checkout' doesn't sync submodule state when switching > > > > > branches. > > > > > > > > Do you happen to know how exactly that happens? > > > > > > For any given branch the submodule is synced to a given git commit hash. > > > If the submodule checkout is not synced to the same commit hash it will > > > show as dirty, and if you git add this pending change, it'll record that > > > new submodule commit hash. Seeing dirty state is common when you switch > > > between branches, either side of a git master change that updated a > > > submodule. > > I see. It is interesting. > > > > So apparently what you want is ignore submodule > > changes, right? If yes this is close to what we want: > > > > git submodule update --checkout testsub > > git update-index --skip-worktree testsub > > > > A script checking out the submodule can just run this > > command. > > The problem happens not when you check out the submodule, but when > you do basic not-submodule-related git operations like > "git checkout my-working-branch". The fix would be if git itself > automatically kept submodule state in sync with the main repo's > branch. But it doesn't, so the UI is a massive beartrap. > > -- PMM
If this is what you want, you can make it do that too: $ cat .gitmodules [submodule "testsub"] path = testsub recurse = true url = /tmp/testsub/ git checkout (and a bunch of other commands) will now recurse into this submodule. -- MST