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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html