Duy Nguyen <pclo...@gmail.com> writes:

> On Sat, Apr 20, 2013 at 8:05 PM, Michael Heemskerk
> <mheemsk...@atlassian.com> wrote:
>> When the client sends a 'shallow' line for an object that the server does
>> not have, the server currently dies with the error: "did not find object
>> for shallow <obj-id>". The client may have received the object from a
>> different server, or the object may have been garbage collected by the
>> server. In either case, the object is not relevant for calculating the pack
>> that is to be sent and can be safely ignored.

For the purpose of generating a pack, these shallow boundaries are
irrelevant.  The above describes only that part.

But the shallow list is also used to compute the updated boundary
(i.e. "this client does not have a valid history behind these
commits")?  When we know their current shallow boundary, after
sending history that crosses that boundary, we can tell them "before
this fetch, you did not have any history behind this commit, but we
know that you now have a bit more. Update your record with these new
boundaries. You still do not have any history behind these commits."
That is how deepening works.

When you receive a shallow boundary unknown to you, it might not
hurt if you keep it and parrot it at the end, so that the fetcher
will still remember that it does not have any history behind the
commit.  There may be reasons why doing so is not sufficient and we
have to reject clients whose history is truncated at a place unknown
to us.

You would declare "now you have everything behind that unknown
shallow boundary", if you ignore an unknown shallow boundary and do
not send it back.

That sounds ourright wrong to me. You simply do not know enough to
make such a declaration.

I do not seem to find the patch you are responding to, so I do not
know how the patch handled the unshallowing part, but the impression
I got from reading the log message quoted is that the patch was not
even aware of the issue.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to