Re: [PATCH] gitmodules: recurse by default

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

On Wed, Oct 12, 2022 at 08:51:51AM +0100, Daniel P. Berrangé wrote:
> On Tue, Oct 11, 2022 at 06:32:40PM -0400, Michael S. Tsirkin wrote:
> > On Fri, Oct 07, 2022 at 12:09:40PM +0100, Daniel P. Berrangé wrote:
> > > On Fri, Oct 07, 2022 at 11:45:56AM +0100, Daniel P. Berrangé wrote:
> > > > On Fri, Oct 07, 2022 at 06:11:25AM -0400, Michael S. Tsirkin wrote:
> > > > > On Fri, Oct 07, 2022 at 09:07:17AM +0100, Daniel P. Berrangé wrote:
> > > > > > On Thu, Oct 06, 2022 at 08:24:01PM -0400, Michael S. Tsirkin wrote:
> > > > > > > On Thu, Oct 06, 2022 at 07:54:52PM +0100, Daniel P. Berrangé wrote:
> > > > > > > > On Thu, Oct 06, 2022 at 07:39:07AM -0400, Michael S. Tsirkin wrote:
> > > > > > > > > The most commmon complaint about submodules is that
> > > > > > > > > they don't follow when one switches branches in the
> > > > > > > > > main repo. Enable recursing into submodules by default
> > > > > > > > > to address that.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > > > > > > > ---
> > > > > > > > >  .gitmodules | 23 +++++++++++++++++++++++
> > > > > > > > >  1 file changed, 23 insertions(+)
> > > 
> > > snip
> > > 
> > > > > I just retested and it's not working for me either :(
> > > > > I was sure it worked but I guess the testing wasn't done properly.
> > > > > Back to the drawing board sorry.
> > > > 
> > > > I think the problem is that this setting doesn't apply in the context
> > > > of .gitmodules. Various commands take a '--recurse-submodules' parameter,
> > > > and like many params this can be set in the .git/config file. The
> > > > problem is .git/config isn't a file we can influence automatically,
> > > > it is upto the dev to set things for every clone they do :-(
> > > 
> > > With the correct setting in my .git/config, I've just discovered
> > > an unexpected & undesirable consequence of using recurse=true.
> > > It affects the 'push' command. If your submodule contains a hash
> > > that is not present in the upstream of the submodule, then when
> > > you try to push, it will also try to push the submodule change.
> > > 
> > > eg, I have a qemu.git branch 'work' and i made a change to
> > > ui/keycodemapdb. If I try to push to my gitlab fork, whose
> > > remote I called 'gitlab', then it will also try to push
> > > ui/keycodemapdb to a fork called 'gitlab'.  Except I don't
> > > have any such fork existing, so my attempt to push my qemu.git
> > > changes fails because of the submodule.
> > > 
> > > This is going to be annoying to people who are working on branches
> > > with updates to the git submodules if we were to set recurse=true
> > > by default, as they'll have to also setup remotes for submodules
> > > they work on.
> > > 
> > 
> > Well this seems like a reasonable thing to do, no?
> > 
> > If you push qemu commit referring to hash 0xABC, you want
> > that 0xABC to be available in the remote, no?
> > Otherwise how will people fetching your tree check it out?
> 
> Don't assume I'm making it available for other people. I push to
> remotes simply for moving code around for myself between machines.
> I still have the submodule code I need elsewhere, so forcing me
> to push the submodule & main repos so the same named remote is
> getting in the way. 
> 
> With regards,
> Daniel

So you are pushing this main tree but the submodule won't be
needed there? Sounds like an unusual enough thing that
it's reasonable to ask user to tweak config to enable it.

> -- 
> |: 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 :|