All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.