On Wed, Jan 9, 2013 at 9:53 AM, Junio C Hamano <gits...@pobox.com> wrote:
>  * First, let's *not* do "git fetch --depth=inf"; if you want to
>    unplug the bottom of your shallow clone, be more explicit and
>    introduce a new option, e.g. "git fetch --unshallow", or
>    something.

No problem. "Something" could be --no-depth or --no-shallow. I think
any of them is better than --unshallow.

>  * We would like to update "clone --depth=1" to end up with a tip
>    only repository, but let's not to touch "git fetch" (and "git
>    clone") and make them send 0 over the wire when the command line
>    tells them to use "--depth=1" (i.e. let's not do the "off-by-one"
>    thing).

You can't anyway. Depth 0 on the wire is considered invalid by upload-pack.

>    Instead, fix "upload-pack" (the bug is in get_shallow_commits()
>    in shallow.c, I think), so that it counts correctly.  When the
>    other end asks for a history with 1-commit deep, it should return
>    a history that is 1-commit deep, and tell the other end about the
>    parents of the returned history, instead of returning a history
>    that is 2 commmits deep.  So when talking with a newer server,
>    clients will get correct number of commits; when talkng with an
>    older server, clients will get a bit more than they asked, but
>    nothing will break.

I'll need to look at get_shallow_commits() anyway for the unshallow
patch. I'll probably do this too.
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