git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heiko Voigt <hvoigt@hvoigt.net>
To: Jens Lehmann <Jens.Lehmann@web.de>
Cc: Henri GEIST <geist.henri@laposte.net>,
	"Shawn O. Pearce" <spearce@spearce.org>,
	git@vger.kernel.org, Pat Thoyts <patthoyts@users.sourceforge.net>
Subject: Re: Re: [PATCH/RFC] git-gui: Add a 'recursive' checkbox in the clone menu.
Date: Thu, 6 Mar 2014 23:00:34 +0100	[thread overview]
Message-ID: <20140306220034.GA30645@sandbox-ub> (raw)
In-Reply-To: <5318CE14.1090000@web.de>

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

  reply	other threads:[~2014-03-06 22:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-04 23:01 [PATCH/RFC] git-gui: Add a 'recursive' checkbox in the clone menu Henri GEIST
2014-03-05 18:00 ` Jens Lehmann
2014-03-06  0:15   ` Henri GEIST
2014-03-06 19:35     ` Jens Lehmann
2014-03-06 22:00       ` Heiko Voigt [this message]
2014-03-11 11:07   ` Henri GEIST
2014-03-11 17:34     ` Jens Lehmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140306220034.GA30645@sandbox-ub \
    --to=hvoigt@hvoigt.net \
    --cc=Jens.Lehmann@web.de \
    --cc=geist.henri@laposte.net \
    --cc=git@vger.kernel.org \
    --cc=patthoyts@users.sourceforge.net \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).