On Tue, 30 Mar 2021 at 17:00, Warner Losh <imp@bsdimp.com> wrote:
> submodules have caused me significant pain in rebasing the bsd-user work.
> The way QEMU does things, you wind up with unclean trees after a build,
> which causes grief at times... I for one, would shed no tears at the number of
> submodules dropping to 0.
I agree that submodules are bad, but in general you shouldn't have
an unclean tree after build as a result of them. (The exception I'm
aware of is if you have to 'git checkout' an older revision where a
submodule that exists now didn't exist back then; git leaves the
submodule directory in the source tree and you have to rm it manually.
But that's "after checkout", not "after build".)
It may be that. I routinely have issues when switching back and forth between
3.1 based rebase and tip of master. I chalked it up to some submodule update
that was done as part of the built, but I could well be wrong. subrepos are a
thing I've not managed so my subrepo foo is weak.
The main bear-trap IMHO is that you have to remember to
"git submodule update" when checking out different revs of
trunk to keep the submodules at the right version. I wish
git just automatically kept submodules at the right rev for
whatever trunk rev you're currently on.
I'll have to try it next time. Maybe it was the only hassle and I was unaware.
But hopefully I'll be focused on doing a 'logical rebase' of committable things
that I've started and that will ultimately render this problem obsolete for
me.
Warner