Re: [RFC/PATCH 0/7] Rework git core for native submodules
- From
John Keeping <john@keeping.me.uk>
- Date
- Apr 7, 2013, 17:02 UTC
- Message-ID
- <20130407170201.GH2222@serenity.lan>
- In-Reply-To
- <CALkWK0kSF_q0o1V6BhO6X2jKAJQxNQ0c6MCi5o=jZdMwrba48g@mail.gmail.com>
On Sun, Apr 07, 2013 at 10:12:28PM +0530, Ramkumar Ramachandra wrote:
Show 18 quoted lines
> John Keeping wrote: > > Meaning that every repository using submodules need to have a flag day > > when all of the people using it switch to the new Git version at once? > > No, I would be totally against a migration that involves a flag-day. > What I meant is that having old-style submodule side-by-side with > new-style submodules is confusing (think about people using an older > version and getting confused), and that we should disallow it. Users > will still be able to use existing repositories with new versions of > git with a few caveats: > 1. They won't be able to add new new submodules without migrating all > existing submodules. > 2. git ls-tree will show the in-tree object incorrectly as a link (ie. > not commit). > > That's about it, I think. Obviously, everyone working on the > repository has to upgrade to a new version of git before they can use > new-style submodules.
So not a flag day, but still some point at which the repository transitions to "will not work with Git older than version X". And if you need to add a new submodule then you cannot delay that transition any longer.
Show 6 quoted lines
> > I think you need a much better argument than "it makes the > > implementation more beautiful" to convince users that a flag day is > > necessary. > > There is no flag day necessary, and that is not my argument at all: > new-style submodules brings lots of new functionality to the table.
I haven't seen anywhere a concise list of what functionality this is. Do you have a simple bulleted list of what new features this would allow?