You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
to improve the support of this kind of clone workflow internally.
35
+
36
+
And for some time this was thought of as just a small manpower problem. A
37
+
few month of dedicated work by anyone could probably fix that. It was
38
+
even proposed as a Google Summer of Code (GSoC) project.
39
+
40
+
Over time though Git developers realized that it was not so easy
41
+
because some very careful design was needed, and it was removed from
42
+
the list of possible GSoC projects.
43
+
44
+
So it was very exciting to see a number of new proposals pop up on the
45
+
list during the last few months.
46
+
47
+
It started on February 5 with
48
+
[a "Resumable clone revisited, proof of concept" patch series by Duy Nguyen](http://thread.gmane.org/gmane.comp.version-control.git/that/)
49
+
where he wrote:
50
+
51
+
> I was reminded by LWN about this. Annoyed in fact because it's
52
+
> called a bug while it looks more like an elephant.
53
+
54
+
and pointing to [a LWN.net article](https://lwn.net/Articles/674392/)
55
+
that reports about
56
+
[Sarah Sharp speaking at the SCALE 14x conference](https://www.socallinuxexpo.org/scale/14x/presentations/improving-diversity-maslows-hierarchy-needs):
57
+
"she noted that Git still does not support interrupting and resuming
58
+
download operations, which is an important bug to fix."
59
+
60
+
Then on February 10 Shawn Pearce sent
61
+
[an 'RFC: Resumable clone based on hybrid "smart" and "dumb" HTTP' proposal](http://thread.gmane.org/gmane.comp.version-control.git/285921/)
62
+
that he had discussed internally with other people at Google where he works.
63
+
64
+
This was followed on March 2 by
65
+
[an email called "Resumable git clone?"](thread.gmane.org/gmane.comp.version-control.git/288088/)
66
+
from Josh Triplett, a well known Linux Kernel developer, who asked:
67
+
68
+
> In a discussion elsewhere, Al Viro suggested taking the partial pack
69
+
> received so far, repairing any truncation, indexing the objects it
70
+
> contains, and then re-running clone and not having to fetch those
71
+
> objects. This may also require extending receive-pack's protocol for
72
+
> determining objects the recipient already has, as the partial pack may
73
+
> not have a consistent set of reachable objects.
74
+
>
75
+
> Before starting down the path of developing patches for this, does the
76
+
> approach seem potentially reasonable?
77
+
78
+
Josh talks about Al Viro who is another well known Linux Kernel
79
+
developer, and it's interesting to see Linux Kernel developers
80
+
interested again in taking part in Git development. It reminds some
81
+
old timers about the "good old time".
82
+
83
+
All these proposals have been discussed by many important Git
84
+
developers and reviewers like Stefan Beller, Junio Hamano, Johannes
85
+
Schindelin, Jonathan Nieder, Eric Sunshine, Jeff King, Elia Pinto.
86
+
87
+
About Shawn's proposal there was also an interesting potential
88
+
security issue called out by Blake Burkhart. And other people like
89
+
Bhavik Bavishi and Konstantin Ryabitsev also took part of the
90
+
discussion following Josh's email.
91
+
92
+
From the last discussions about Josh's email, it appeared that Git
93
+
developers favored Shawn's proposal over others, and maybe that
94
+
Shawn's proposal was going to be worked on soon.
95
+
96
+
Then on March 5 Kevin Wern sent
97
+
[an email called "Resumable clone"](thread.gmane.org/gmane.comp.version-control.git/288306/),
98
+
where he said he began looking at relevant code to start working on it, and he asked:
99
+
100
+
> Is someone working on this currently? Are there any things I should
101
+
> know moving forward? Is there a certain way I should break
102
+
> down/organize the feature when writing patches?
103
+
104
+
Duy answered that "Resumable clone is happening." And pointed to
0 commit comments