Thread (10 messages) flat view 10 messages, 3 authors, 2016-06-15

Re: [BUG?] fetch into shallow sends a large number of objects

From: Jeff King <hidden>
Date: 2016-06-15 23:08:39

Possibly related (same subject, not in this thread)

On Tue, Mar 08, 2016 at 07:53:35AM +0700, Duy Nguyen wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help