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. -- Duy -- 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
