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