From: Jeff King <peff@peff.net>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: [BUG?] fetch into shallow sends a large number of objects
Date: Tue, 8 Mar 2016 07:21:26 -0500 [thread overview]
Message-ID: <20160308122126.GB18535@sigill.intra.peff.net> (raw)
In-Reply-To: <CACsJy8C-Wfh16jroWACEFybtnhwYX91GvgGwk8XxJRft4ZURSw@mail.gmail.com>
On Tue, Mar 08, 2016 at 07:53:35AM +0700, Duy Nguyen wrote:
> > I also do not offhand think of a good way to use the topology or
> > timestamp to figure out the best "depth" to truncate the side branch
> > at. The server side may be able to figure out that things before 'F'
> > in your picture is not relevant for a client that has the shallow
> > cut-off at 067f265, but the side branch can be forked arbitrarily
> > long in the past, or it may not even share the ancient part of the
> > history and has its own root commit.
>
> If a shallow point can reach root without seeing another shallow
> point, we can mark all reachable commits from it shallow. If it sees
> another shallow point, maybe we can mark at the merge point of them..
Hmph, I read your email before sending my other response, but somehow I
didn't quite understand what you were saying. Now after having written
my long-winded other one, I think I just re-invented the same thing you
are proposing here. ;)
> We can also send "here is --depth=10, but only apply it on new refs".
> That should mitigate the problem a bit. But I'm not sure if I can
> solve it completely.
I think "new refs" isn't something we can rely on. For example, in this
case the old history may have been merged in and the ref deleted before
the fetcher shows up.
-Peff
next prev parent reply other threads:[~2016-03-08 12:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-07 22:15 [BUG?] fetch into shallow sends a large number of objects Jeff King
2016-03-07 23:47 ` Junio C Hamano
2016-03-08 0:53 ` Duy Nguyen
2016-03-08 12:21 ` Jeff King [this message]
2016-03-08 12:14 ` Jeff King
2016-03-08 12:33 ` Duy Nguyen
2016-03-08 13:25 ` Jeff King
2016-03-08 13:30 ` Jeff King
2016-03-08 23:02 ` Duy Nguyen
2016-03-10 12:20 ` Duy Nguyen
2016-03-10 21:10 ` Jeff King
2016-03-10 21:26 ` Junio C Hamano
2016-03-10 21:40 ` Jeff King
2016-03-11 0:47 ` Duy Nguyen
2016-03-11 16:53 ` Junio C Hamano
2016-03-11 18:16 ` Jeff King
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160308122126.GB18535@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).