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

Reply via email to