From: "Daniel P. Berrange" <berrange@redhat.com>
To: "Michal Suchánek" <msuchanek@suse.de>
Cc: Thomas Huth <thuth@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
QEMU Developers <qemu-devel@nongnu.org>,
Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] Yet another git submodule rant
Date: Wed, 8 Nov 2017 12:34:17 +0000 [thread overview]
Message-ID: <20171108123417.GQ12670@redhat.com> (raw)
In-Reply-To: <20171108130527.0afeb899@kitsune.suse.cz>
On Wed, Nov 08, 2017 at 01:05:27PM +0100, Michal Suchánek wrote:
> On Wed, 8 Nov 2017 10:25:29 +0000
> "Daniel P. Berrange" <berrange@redhat.com> wrote:
>
> > On Wed, Nov 08, 2017 at 10:57:21AM +0100, Thomas Huth wrote:
> > >
> > > That automatic git submodule stuff now broke my workflow again. I
> > > usually keep the git repository on my laptop and then simply rsync
> > > the sources (without .git directories) to my target machine to
> > > compile it there. Used to work great for years. Now it's broken,
> > > the build process complains:
> >
> > Excluding the .git dir will be a problem - that needs to exist, unless
> > you are building from tar.xz (where we will bundled all the submodule
> > sources together in the tar.xz).
> >
> > If you really want to exclude the .git directories, then instead of
> > doing an rsync, then use the scripts/archive-source.sh tool to create
> > an archive of all the sources (which bundles required submodules)
> > and unpack that on your target machine. Then all submodule handling
> > on the target will be skipped.
>
> This probably does not work because it archives committed sources and
> not actual sources.
Actually that's not quite correct - if it sees you have non-comitted
changes, and will use 'git stash create' to capture them in the archive
it creates. So it would only miss brand new files which have not yet
been 'git add'ed
> > > I've got the feeling that all this submodule crap is constantly
> > > causing pain ... do we really need this? Can't we find another
> > > solution instead? Or at least stop modifying files automatically in
> > > the $SRC_PATH ?
> >
> > We *have* to modify SRC_PATH, as that's where git submodule checkouts
> > live. If we didn't do that, then people would end up having failed
> > build due to submodules not existing, or even worse, having a silently
> > incorrect build due to using the wrong checked out version.
>
> And that's another reason why submodules are bad thing.
>
> So again, can this be done without submodules?
>
> Let somebody else do the testing and polishing of this pre-alpha git
> feature.
Honestly I think the submodule stuff is working pretty well - a handful
of people have mentioned problems and we've addressed most of them or
illustrated alternative approaches to deal with it. For most developers
it has been pretty much transparent and just works, or we would have
seen alot more noise.
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 :|
next prev parent reply other threads:[~2017-11-08 12:34 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-08 9:57 [Qemu-devel] Yet another git submodule rant Thomas Huth
2017-11-08 10:25 ` Daniel P. Berrange
2017-11-08 12:05 ` Michal Suchánek
2017-11-08 12:34 ` Daniel P. Berrange [this message]
2017-11-08 12:43 ` Michal Suchánek
2017-11-08 12:55 ` Daniel P. Berrange
2017-11-08 10:53 ` Gerd Hoffmann
2017-11-08 11:48 ` Thomas Huth
2017-11-08 13:30 ` Philippe Mathieu-Daudé
2017-11-08 16:09 ` Laszlo Ersek
2017-11-08 12:26 ` Philippe Mathieu-Daudé
2017-11-08 13:01 ` Daniel P. Berrange
2017-11-10 10:35 ` Alexey Kardashevskiy
2017-11-10 10:41 ` Daniel P. Berrange
2017-11-10 13:46 ` Alexey Kardashevskiy
2017-11-10 14:01 ` Peter Maydell
2017-11-11 0:15 ` Alexey Kardashevskiy
2017-11-10 14:22 ` Daniel P. Berrange
2017-11-11 1:10 ` Alexey Kardashevskiy
2017-11-20 1:06 ` Alexey Kardashevskiy
2017-11-09 3:02 ` Alexey Kardashevskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171108123417.GQ12670@redhat.com \
--to=berrange@redhat.com \
--cc=kraxel@redhat.com \
--cc=msuchanek@suse.de \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).