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
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"
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