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

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 07.04.2013 20:44, schrieb Ramkumar Ramachandra:
> 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.
> 
> Really?  git-submodule.sh was written in 2007, and does not have git
> mv or cd-to-toplevel restriction removed to date.  What does that say
> about git-submodule?

That there is still some work to do, which I never denied and am
actively working on (see "git mv" support in pu, which tackles one
of the UI issues you mentioned).

> I specifically said end-user's perspective.  Why exactly would I be
> talking about the advantages of the link object?

Because they are all that matters when it comes to decide if a link
object should be introduced to replace the current model. We should
discuss the differences in the UI that result from introducing such
an object, not the stuff that is still missing from our current
implementation (as that has to be coded either way and can not be
taken in favor of either solution). And we can additionally also
talk about the differences in hacking on git, where I concede that
putting everything into a single object could lead to shorter code
than having to consult a .gitmodules file for that (even though I
believe these arguments are much less important than UI changes).

Just to be sure: I think we agree that both approaches are capable
of allowing all relevant use cases, because they store the same
information?

Disclaimer: I am not opposed to the link object per se, but after
all we are talking about severely changing user visible behavior.
So I want to see striking evidence that we gain something from it,
discussed separately from UI deficiencies of the current code (no
cd-to-toplevel please ;-).

So I started putting together a list of advantages and one of
disadvantages of the new link object compared to the current model.
We can extend and refine that to see what your proposal would mean
for us. After all we are talking about severely changing user
visible behavior, so we need convincing reasons to do that.


Advantages:

* Information is stored in one place, no need to lookup stuff in
  another file/blob.

* Easier coding, as we find all information in a single object.

(I did not forget to add the point that you currently need a
checked out work tree to access the .gitmodules file, as there is
ongoing work to read the configuration directly from the database)

(Another advantage would be that it is easier to merge the link
object, but a - still to be coded - .gitmodules aware merge driver
would work just as well)


Disadvantages:

* Changes in user visible behavior, possible compatibility
  problems when Git versions are mixed.

* Special tools are needed to edit submodule information where
  currently a plain editor is sufficient.

* merge conflicts are harder to resolve and require special git
  commands, solving them in .gitmodules is way more intuitive
  as users are already used to conflict markers.

* A link object has no unstaged counterpart that a file easily
  has. What would that mean for adding a submodule and then
  unstaging it (or how could we add a submodule unstaged, like
  you proposed in another email)?

(I think when we also put the submodule name in the object we
could also retain the ability to repopulated moved submodules
from their old repo, which is found by that name)


I'm not saying that this list is complete, I just wrote down
what came to mind. When we e.g. find workable solutions to the
Disadvantages we can remove them from the list and append them
in parentheses for later reference like I did here. Does that
sound like a plan?