[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why we should avoid new submodules if possible

From: Warner Losh
Subject: Re: Why we should avoid new submodules if possible
Date: Wed, 28 Sep 2022 07:06:44 -0600

On Wed, Sep 28, 2022 at 6:44 AM Michael S. Tsirkin <mst@redhat.com> wrote:
On Wed, Sep 28, 2022 at 10:37:14AM +0100, Daniel P. Berrangé wrote:
> There's also the perenial problem that developers frequently send
> patches that mistakenly include submodule changes, which is related to the
> way that 'git checkout' doesn't sync submodule state when switching branches.

Do you happen to know how exactly that happens?

Here's how it happens to me.

% git checkout master
% git checkout -b bsd-user-2022q4
# bring changes in, doesn't matter
# Build a few times
# time passes, master upstream evolves, submodules move
% git checkout master
% git pull # master fast forwards
% git rebase -i master bsd-user-2022q4

at this point I have to do unnatural git submodule recursive things to make it stop
complaining about how all the submodules are now 'modified' because they have
moved on the master branch.

It is real, lasting, lingering pain and a large part of the reason that I refuse to allow FreeBSD
to use submodules[*]. It's just too much extra hassle for no gain at all (at least for me, I
see only the pain and no benefits to me or anybody else). I've sent at least three review
requests that have this pollution in it since it's hard to avoid if you press forward after the
rebase not to have something swept up into an innocuous change.


[*] They are also generally a poor match for FreeBSD since we rarely import things
verbatim, unchanged from upstreams that have well-oiled CI to give us assurance
that things are good...

reply via email to

[Prev in Thread] Current Thread [Next in Thread]