On Thu, Mar 06, 2014 at 08:35:48PM +0100, Jens Lehmann wrote: > Am 06.03.2014 01:15, schrieb Henri GEIST: > > Le mercredi 05 mars 2014 à 19:00 +0100, Jens Lehmann a écrit : > >> Am 05.03.2014 00:01, schrieb Henri GEIST: > >> - Wouldn't it be easier to pass the '--recurse-submodules" > >> option to the "git clone" call for the superproject instead > >> of adding the _do_clone_submodules() function doing a > >> subsequent "git submodule update --init --recursive"? That > >> is also be more future proof with respect to the autoclone > >> config option we have in mind (which would add that behavior > >> for "git clone" itself, making the call you added redundant). > > > > That is what I planned to do at beginning. > > But git-gui never call git clone anywhere. > > It make the clone step by step with a long and complicated list of > > commands just like a Tcl rewrite of git-clone. > > Have a look on the function _do_clone2 in choose_repository.tcl. > > You're right, it does fetch followed by read-tree ... so my > proposal doesn't make much sense here, sorry for bothering you > without checking the source first. > > > As I suspect there should be a good reason for this that I did not > > understand I have choose to not refactoring it. > > That makes sense. Shawn, could you shed some light on why clone > is coded again using plumbing in git gui instead of just calling > the clone command? I think because git gui is using plumbing everywhere, it is supposed to be just another porcelain. And I guess that was an intended decision because porcelain might change its output and break git gui. At least thats what I inferred. Cheers Heiko -- 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