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 <m...@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 :|
