From: Jason Paller-Rzepka <hidden> Date: 2016-06-15 23:07:21
Hi all,
Would anyone be willing to help me understand some shallow-clone
behavior? (I found a bug in Dulwich, and I'm looking for some context
so I can determine how to fix it.)
I learned that cgit sometimes performs two fetches for a `git fetch
--unshallow`: one with depth 'infinity', and a subsequent one with
depth zero.
Could anyone answer:
1) What is the purpose of the second fetch?
2) What does this depth of zero mean? Is it the same as a depth of
infinity? (I assume not... but, since I thought the smallest
meaningful depth was 1, I don't know what else it might mean.)
Thank you!
Jason
From: Stefan Beller <hidden> Date: 2016-06-15 23:07:22
On Mon, Nov 30, 2015 at 11:35 AM, Jason Paller-Rzepka
[off-list ref] wrote:
Hi all,
Would anyone be willing to help me understand some shallow-clone
behavior? (I found a bug in Dulwich, and I'm looking for some context
so I can determine how to fix it.)
I learned that cgit sometimes performs two fetches for a `git fetch
--unshallow`: one with depth 'infinity', and a subsequent one with
depth zero.
Is there a condition to trigger this 'sometimes' ?
I just tried reproducing via
$ GIT_TRACE=1 git fetch --unshallow
and could not see a second fetch, but only a
fetch-pack with --depth=2147483647
Could anyone answer:
1) What is the purpose of the second fetch?
2) What does this depth of zero mean? Is it the same as a depth of
infinity? (I assume not... but, since I thought the smallest
meaningful depth was 1, I don't know what else it might mean.)
Thank you!
Jason
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Jeff King <hidden> Date: 2016-06-15 23:07:22
On Fri, Dec 04, 2015 at 12:46:59PM -0800, Stefan Beller wrote:
On Mon, Nov 30, 2015 at 11:35 AM, Jason Paller-Rzepka
[off-list ref] wrote:
quoted
Hi all,
Would anyone be willing to help me understand some shallow-clone
behavior? (I found a bug in Dulwich, and I'm looking for some context
so I can determine how to fix it.)
I learned that cgit sometimes performs two fetches for a `git fetch
--unshallow`: one with depth 'infinity', and a subsequent one with
depth zero.
Is there a condition to trigger this 'sometimes' ?
I just tried reproducing via
$ GIT_TRACE=1 git fetch --unshallow
and could not see a second fetch, but only a
fetch-pack with --depth=2147483647
This seems to reproduce consistently for me:
$ git clone --depth=1 git://github.com/git/git
Cloning into 'git'...
remote: Counting objects: 2925, done.
remote: Compressing objects: 100% (2602/2602), done.
remote: Total 2925 (delta 230), reused 2329 (delta 206), pack-reused 0
Receiving objects: 100% (2925/2925), 6.17 MiB | 10.80 MiB/s, done.
Resolving deltas: 100% (230/230), done.
$ cd git
$ git fetch --unshallow
remote: Counting objects: 185430, done.
remote: Compressing objects: 100% (46933/46933), done.
remote: Total 185430 (delta 140505), reused 181589 (delta 136694), pack-reused 0
Receiving objects: 100% (185430/185430), 52.80 MiB | 10.84 MiB/s, done.
Resolving deltas: 100% (140505/140505), completed with 1784 local objects.
remote: Counting objects: 579, done.
remote: Compressing objects: 100% (579/579), done.
remote: Total 579 (delta 0), reused 579 (delta 0), pack-reused 0
Receiving objects: 100% (579/579), 266.85 KiB | 0 bytes/s, done.
[... fetch output ...]
That looks like two packs being received for the --unshallow case.
-Peff
From: Jason Paller-Rzepka <hidden> Date: 2016-06-15 23:07:22
It appears that it happens when the shallow history grows to include a
commit that's pointed to by a previously unseen tag. For example,
when I deepen a checkout of git to depth 8, I hit v2.5.2, and a second
fetch takes place.
But why would fetching a tag (or set of tags) merit a depth of zero?
Doesn't depth 1 mean "give me the the objects, and none of their
descendants"? Why use 0?
Thanks!
Jason
On Fri, Dec 4, 2015 at 4:27 PM, Jeff King [off-list ref] wrote:
On Fri, Dec 04, 2015 at 12:46:59PM -0800, Stefan Beller wrote:
quoted
On Mon, Nov 30, 2015 at 11:35 AM, Jason Paller-Rzepka
[off-list ref] wrote:
quoted
Hi all,
Would anyone be willing to help me understand some shallow-clone
behavior? (I found a bug in Dulwich, and I'm looking for some context
so I can determine how to fix it.)
I learned that cgit sometimes performs two fetches for a `git fetch
--unshallow`: one with depth 'infinity', and a subsequent one with
depth zero.
Is there a condition to trigger this 'sometimes' ?
I just tried reproducing via
$ GIT_TRACE=1 git fetch --unshallow
and could not see a second fetch, but only a
fetch-pack with --depth=2147483647
This seems to reproduce consistently for me:
$ git clone --depth=1 git://github.com/git/git
Cloning into 'git'...
remote: Counting objects: 2925, done.
remote: Compressing objects: 100% (2602/2602), done.
remote: Total 2925 (delta 230), reused 2329 (delta 206), pack-reused 0
Receiving objects: 100% (2925/2925), 6.17 MiB | 10.80 MiB/s, done.
Resolving deltas: 100% (230/230), done.
$ cd git
$ git fetch --unshallow
remote: Counting objects: 185430, done.
remote: Compressing objects: 100% (46933/46933), done.
remote: Total 185430 (delta 140505), reused 181589 (delta 136694), pack-reused 0
Receiving objects: 100% (185430/185430), 52.80 MiB | 10.84 MiB/s, done.
Resolving deltas: 100% (140505/140505), completed with 1784 local objects.
remote: Counting objects: 579, done.
remote: Compressing objects: 100% (579/579), done.
remote: Total 579 (delta 0), reused 579 (delta 0), pack-reused 0
Receiving objects: 100% (579/579), 266.85 KiB | 0 bytes/s, done.
[... fetch output ...]
That looks like two packs being received for the --unshallow case.
-Peff
From: Stefan Beller <hidden> Date: 2016-06-15 23:07:23
I can reproduce it now. Instead of using my $random version, I just
needed origin/master
to reproduce.
The second fetch is invoked via
(as outputted via GIT_TRACE=1 git -C git fetch --depth=8)
13:44:56.863841 run-command.c:343 trace: run_command:
'fetch-pack' '--stateless-rpc' '--stdin' '--lock-pack' '--thin'
'https://github.com/git/git/'
so it seems like there is no explicit depth given, so I think the 0
comes from the initialization step and nobody touched it to fill with
meaningful values.
From: Jeff King <hidden> Date: 2016-06-15 23:07:23
On Fri, Dec 04, 2015 at 04:38:16PM -0500, Jason Paller-Rzepka wrote:
It appears that it happens when the shallow history grows to include a
commit that's pointed to by a previously unseen tag. For example,
when I deepen a checkout of git to depth 8, I hit v2.5.2, and a second
fetch takes place.
Yeah. The code is in builtin/fetch.c:backfill_tags.
But why would fetching a tag (or set of tags) merit a depth of zero?
Doesn't depth 1 mean "give me the the objects, and none of their
descendants"? Why use 0?
That comes from this line:
transport_set_option(transport, TRANS_OPT_DEPTH, "0");
That line blame back to b888d61 (Make fetch a builtin, 2007-09-10),
which isn't incredibly helpful.
I think that comes from the original git-fetch.sh, which had:
?*)
# do not deepen a shallow tree when following tags
shallow_depth=
Which makes sense. I think the code at that point is not aware that we
just "unshallowed" and can therefore drop the depth parameter
altogether. But I admit I am not all that familiar with the shallow
code.
+cc Duy, who can probably say something way more intelligent about this
off the top of his head. :)
-Peff