It seems like you posted from the news interface at gmane, and the
annoying are gone now. The patch is still linewrapped (see the
hunk header starting with "@@ -187,26"), but this one I can fix up and
actually take a look ;-).
Explain the exchange that occurs between a client and server when
the client is requesting shallow history and/or is already using
a shallow repository.
Notice the use of word "shallow" here. It talks about the depth of the
history.
+... Commits whose parents are not received as a result are
+defined as shallow and marked as such in the server. This information
+is sent back to the client in the next step.
As it is documented for the first time, we didn't have a formal
terminology for calling these commits and it is this document's
responsibility to come up with a good one. We have used "shallow clone"
and "shallow history", and I agree with the use of adjective in these
contexts, but I am not sure if it is a good idea to call the commits at
the boundary of a shallow history "shallow"---the following sentences do
not parse well at least for me:
"This commit is shallow."
"This commit is not shallow, and it is a direct child of that commit,
which is shallow."
"That commit does not exist in this repository because it is an
ancestor of a shallow commit".
But it may be just me. Better wording ideas, anybody?
By the way, Dscho, the shallow extension was your invention 4 and half
years ago. I think the description in this version is mostly accurate
(modulo the part that talks about an early client termination after
"shallow" and "deepen" are sent), but I'd appreciate if you can comment on
it to improve.
Thanks.
From: Alex Neronskiy <hidden> Date: 2016-06-15 22:51:26
Junio C Hamano <gitster <at> pobox.com> writes:
It seems like you posted from the news interface at gmane, and the
annoying are gone now. The patch is still linewrapped (see the
hunk header starting with "@@ -187,26"), but this one I can fix up and
actually take a look .
So is the one starting with "@@ -215,21 +217,65". Sorry, I failed once again.
It's not cc'ed, either. I'm thinking maybe Scott Chacon also has comments, since
he seems to have written the file I'm modifying?
As it is documented for the first time, we didn't have a formal
terminology for calling these commits and it is this document's
responsibility to come up with a good one. We have used "shallow clone"
and "shallow history", and I agree with the use of adjective in these
contexts, but I am not sure if it is a good idea to call the commits at
the boundary of a shallow history "shallow"---the following sentences do
not parse well at least for me:
"This commit is shallow."
"This commit is not shallow, and it is a direct child of that commit,
which is shallow."
"That commit does not exist in this repository because it is an
ancestor of a shallow commit".
But it may be just me. Better wording ideas, anybody?
Yes, I see... I just transplanted the terminology that the protocol uses. When
"shallow SHA" is written, it means something is at the history boundary. Then
again, when "deepen d" is written, it specifies a depth and not an amount to
increase depth by, so maybe the strings the protocol uses are just bad for human
comprehension.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:51:26
Dear Junio,
On Tue, 7 Jun 2011, Junio C Hamano wrote:
Alex Neronskiy [off-list ref] writes:
By the way, Dscho, the shallow extension was your invention 4 and half
years ago.
Yep, I remember. My iBook died in the process. But I got the job.
I think the description in this version is mostly accurate (modulo the
part that talks about an early client termination after "shallow" and
"deepen" are sent), but I'd appreciate if you can comment on it to
improve.
I will, once I am back to normal after traveling. Unfortunately (for my
Git contributions at least), I will be heavily traveling in the next time,
maybe for the next two years. But as for the patch you requested my
look-over, I expect to have enough time tomorrow, latest coming weekend.
Ciao,
Johannes