Re: Why we should avoid new submodules if possible

["Michael S. Tsirkin" <mst@redhat.com>]

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.
> 
> With regards,
> Daniel

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.



> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|