All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "SZEDER Gábor" <szeder@ira.uka.de>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [RFC/PATCH] clone: make 'git clone -c remote.origin.fetch=<refspec>' work
Date: Mon, 7 Mar 2016 10:33:05 -0500	[thread overview]
Message-ID: <20160307153304.GA23010@sigill.intra.peff.net> (raw)
In-Reply-To: <20160307161931.Horde.TcdEVtHKgSMvScCDUKLclVq@webmail.informatik.kit.edu>

On Mon, Mar 07, 2016 at 04:19:31PM +0100, SZEDER Gábor wrote:

> >Even though I think the original description did not mean to include
> >the fetch refspecs when it talked about configuration taking effect,
> >I think what this change wants to do probably makes sense.
> 
> Well, currently one would have to clone, set additional fetch refspecs,
> fetch again and repack.  Using 'git clone -c <refspecs>' would do it in
> a single step, requiring fewer commands, less time, less data transfer
> and less disk space, which fits the justification of v1.7.7-rc0~90^2
> perfectly.

Yeah, I think your change very much fits the spirit of what the original
commit was trying for.

> >My knee-jerk reaction is to change the last paragraph of your log
> >message to read more like
> >
> >	Always read the fetch refspecs from the newly created config
> >	file, and use that for the initial fetching.
> >
> >and do so even when running with "--single-branch".
> 
> Ok, will change the '--single-branch' codepath as well.
> 
> But before doing so, to avoid a possible misunderstanding on my part:
> I'm not sure how literally you meant that "from the newly created
> config file" part, because it ignores refspecs specified via any
> other means, e.g. 'git -c <fetch-refspec> clone'.  I think the
> initial fetch should be no different from "regular" fetches, and
> should respect all configured fetch refspecs regardless where they
> come from.

IMHO, we should stick to the conceptual model that "git clone" is:

  git init
  git config ... ;# set up remote, etc
  git fetch
  git checkout ;# obviously not for --bare

The implementation has to diverge from that to do certain optimizations,
but absent any good reason not to, I think we should aim for behaving
"as if" those commands were run.

It certainly may produce surprising behavior at times, but at least it
is a conceptually simple mental model.  I do admit, though I haven't
thought hard enough to know whether there are any terrible gotchas
there.

-Peff

  reply	other threads:[~2016-03-07 15:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-07  1:11 [RFC/PATCH] clone: make 'git clone -c remote.origin.fetch=<refspec>' work SZEDER Gábor
2016-03-07  1:36 ` Junio C Hamano
2016-03-07 15:19   ` SZEDER Gábor
2016-03-07 15:33     ` Jeff King [this message]
2016-03-07 20:01       ` Junio C Hamano
2016-03-30 14:53       ` [PATCH v2] clone: respect configured fetch respecs during initial fetch SZEDER Gábor
2016-03-31 16:15         ` Junio C Hamano
2016-03-31 18:56           ` Junio C Hamano
2016-03-31 20:50             ` SZEDER Gábor
2016-03-31 22:44               ` Junio C Hamano
2016-04-01  4:20                 ` SZEDER Gábor
2016-04-01  0:30           ` SZEDER Gábor

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=20160307153304.GA23010@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=szeder@ira.uka.de \
    /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.