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