Junio C Hamano wrote:
> When you add a submodule with the current system, bypassing "git
> submodule add", you can either
>     (1) "git clone $URL here" and then "git add here"; or
>     (2) "git init here" and then "git add here".
> Because you didn't say what you are aiming for in the grander
> picture, I thought you were "making the UI simpler"

In the original email, I wrote:
>  Okay, so this is part of my evil plan to make 'git add' DTRT wrt
>  submodules, and deprecate 'git submodule add' (I have some code
>  written down, but this is a prerequisite: I don't like the
>  .git/modules nonsense).

I'm not sure how you inferred "making the UI simpler" from that, or the tests.

> by making it
> unnecessary for the users to say "git clone" himself as a separate
> step before doing "git add". In such a world, "add" would internally
> run "clone". If that were the case (I now know it is not), then the
> configuration _is_ unnecessary, and it is perfectly valid to
> question why you thought it is needed.

No, I would _never_ propose something that ugly.  Neither my code,
tests, nor my commit message indicates that I was going in that
direction, so I don't know where you got the idea from.

> But if that is the direction you are aiming for, would it be
> possible that the same configuration variable can and should cover
> the use case (2) as well?  After all, between "git init here" and
> "git add here", the user may say (cd here && git pull $URL) and the
> expected end result would be the same as (1), no?

Good point.  Yes, I would definitely want that.

> If "clone" just calls init_db(), I would imagine that it might be
> trivial to cover both cases by telling init_db() to pay attention to
> the configuration, without doing much in the "clone" itself.

Right.  I'll start hacking.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to