Re: [RFC/PATCH 0/7] Rework git core for native submodules

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 7, 2013, 19:06 UTC
Message-ID: <CALkWK0=v6SD_zEw=taauYWvYD5pHzdrED0vrhuFHKeS2zfgxSw@mail.gmail.com>
In-Reply-To: <20130407185905.GK2222@serenity.lan>

John Keeping wrote:

> With the clarifications Ram's provided in this thread, I think there are
> also some important regressions in functionality in his proposal (at
> least as it currently stands), particularly losing the .gitconfig
> overrides.

If we want the entire feature list in the very first iteration, it's going to be huge.

Show 7 quoted lines

> The only proposed change that seems to me to be impossible with the
> current .gitmodules approach is the "submodule in a non-initialized
> submodule" feature, but I've never seen anyone ask for that and it seems
> likely to open a whole can of worms where the behaviour is likely to
> vary with $PWD.  The current hierarchical approach provides sensible
> encapsulation of repositories and is simple to understand: once you're
> in a repository nothing above its root directory affects you.

That can be implemented in the current submodule system too, fwiw.

Show 7 quoted lines

> It doesn't seem to me that "it's harder than I'd like to add a feature I
> want" is a good reason to subject all users of submodules to a lot of
> pain migrating to some new implementation that doesn't work the way
> they're used to and which will mean they have to deal with complaints
> when people using an older version of Git can't clone their repository
> (and I doubt we want this mailing list to be flooded with such
> complaints either).

Like I've said before: there is nothing that _cannot_ be done with the
current submodule system.  To see the real advantages of this new
submodule system, you have to think like a developer, not an end-user.
 Focusing just on end-user happiness is a very myopic way to develop
software, and I think the git community is better than that.