[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why we should avoid new submodules if possible
From: |
Michal Suchánek |
Subject: |
Re: Why we should avoid new submodules if possible |
Date: |
Wed, 28 Sep 2022 23:43:03 +0200 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
On Wed, Sep 28, 2022 at 05:07:48PM -0400, Michael S. Tsirkin wrote:
> On Wed, Sep 28, 2022 at 10:48:03PM +0200, Michal Suchánek wrote:
> > Hello,
> >
> > On Tue, Jun 28, 2022 at 07:00:59AM -0400, Michael S. Tsirkin wrote:
> >
> > >
> > > git submodules are awkward basically because they are an automated wget.
> > > I don't think an explicit wget is much better ... but
> > > looks like I'm alone in this. Oh well.
> > > So it will be a weird dance of wget a tarball, unpack, generate
> > > ISO and run. God help you if you need to patch the test - it's
> > > wget all the way down.
> >
> > That's the problem - the submodules are not automated. They are
> > half-automated, and the rules for when the automation works and for when
> > the automation falls apart are not intellibible for the general Joe
> > Developer.
> >
> > You might spend a few days studying how they behave exactly, and then you
> > will know. But unless you will use them every day you will forget again,
> > because the rules do not lend themselves to some abstraction easily
> > understood by humans.
> >
> > Thanks
> >
> > Michal
>
> But why would learning a different tool be easier?
a) it's working lends itself to explaining in human-intelligible
concepts
b) it's used elsewhere as well
Thanks
Michal
- Re: Why we should avoid new submodules if possible, (continued)
Re: Why we should avoid new submodules if possible, Michael S. Tsirkin, 2022/09/28
Re: Why we should avoid new submodules if possible, Warner Losh, 2022/09/28
Re: Why we should avoid new submodules if possible, Michal Suchánek, 2022/09/28