Hi Junio,

> Doing it "correctly" (in the shorter term) would involve:
>  - adding a capability on the sending side "fixed-off-by-one-depth"
>    to the protocol, and teaching the sending side to advertise the
>    capability;
>  - teaching the requestor that got --depth=N from the end user to
>    pay attention to the new capability in such a way that:
>    - when talking to an old sender (i.e. without the off-by-one
>      fix), send N-1 for N greater than 1.  Punt on N==1;
>    - when talking to a fixed sender, ask to enable the capability,
>      and send N as is (including N==1).
>  - teaching the sending side to see if the new behaviour to fix
>    off-by-one is asked by the requestor, and stop at the correct
>    number of commits, not oversending one more.  Otherwise retain
>    the old behaviour.

While implementing the above, I noticed my fix now introduced an
off-by-one error the other way. When investigating, I found this commit:

        commit 682c7d2f1a2d1a5443777237450505738af2ff1a
        Author: Nguyễn Thái Ngọc Duy <pclo...@gmail.com>
        Date:   Fri Jan 11 16:05:47 2013 +0700

            upload-pack: fix off-by-one depth calculation in shallow clone

            get_shallow_commits() is used to determine the cut points at a given
            depth (i.e. the number of commits in a chain that the user likes to
            get). However we count current depth up to the commit "commit" but 
            do the cutting at its parents (i.e. current depth + 1). This makes
            upload-pack always return one commit more than requested. This patch
            fixes it.

            Signed-off-by: Nguyễn Thái Ngọc Duy <pclo...@gmail.com>
            Signed-off-by: Junio C Hamano <gits...@pobox.com>

Which actually seems to fix the off-by-one bug that is described in this
thread, but without going through the hoops of preserving current
behaviour for older git versions (that is, it makes behaviour dependent
on server version instead of client version).

Does this mean the discussion in this thread is meaningless, or is that
commit not intended to be the final fix?

In any case, IIUC that particular patch makes a piece of the existing
code dead, which needs to be removed.


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