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
next prev parent 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.