[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [RFC/PATCH 0/7] Rework git core for native submodules
From:       John Keeping <john () keeping ! me ! uk>
Date:       2013-04-07 18:59:05
Message-ID: 20130407185905.GK2222 () serenity ! lan
[Download RAW message or body]

On Sun, Apr 07, 2013 at 08:34:27PM +0200, Jens Lehmann wrote:
> The whole feature list is full of red herrings like this which
> have nothing to do with the advantages of a new object, but talk
> about UI issues which are easy to solve in both worlds.

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.

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.

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).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]