Re: [PATCH] gitmodules: recurse by default

["Daniel P. Berrangé" <berrange@redhat.com>]

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