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

[John Keeping <john@keeping.me.uk>]

On Sun, Apr 07, 2013 at 09:21:44PM +0530, Ramkumar Ramachandra wrote:
> I suspect you're overtly worried about the fallout of such a
> disruptive change.  If so, you could've just said: "Ram, I like the
> idea.  But what breakages do you estimate we'll have to deal with?"
> instead of attacking the idea and repeatedly questioning its purpose.
> So, I'll make a rough guess based on the first iteration I intend to
> get merged:
> 
> - Not all the git submodule subcommands will work. add/ status/ init/
> deinit are easy to rewrite, but stuff like --recursive and foreach
> might be slightly problematic as I already pointed out earlier.  We'll
> have to code depending on how far you think the first iteration should
> go.  After a few iterations, we can make 'git submodule' just print
> "This command is deprecated.  Please read `man gitsubmodules`."
> 
> - All existing repositories with submodules will not be supported.  My
> plan to deal with this: Have git-core code detect commit objects
> in-tree and disable things like diff.  As soon as the user executes
> the first 'git submodule' command, remove all existing submodules,
> along with .gitmodules and re-add them as link objects.  Then print a
> message saying: "We've just migrated your submodules to the new
> format.  Please commit this."

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?

How happy do you expect users to be if they have to remember to use
different Git version to work on different repositories because some
have switched and some haven't?

>From a user's point of view, the current submodule support mostly works
very well.  Yes there are some annoyances ("you are not at the top
level") and some more advanced features require a bit too much work
(moving a submodule) but in normal usage it works very well in my
experience.

I think you need a much better argument than "it makes the
implementation more beautiful" to convince users that a flag day is
necessary.

> That's really it.  It's certainly not earth-shattering breakage;

For most users, the migration you've outlined above is exactly that.

Even looking just at commits sent to this list, I've seen users on
versions of Git from 1.7.10 to builds from next/pu in just the last
week.  Coordinating a flag day for even a slightly popular repository is
going to cause a lot of pain.