Here to outline my current thinking. Note that this is unrelated to the "git clone --bottom=v1.2.3" to say "I do not care about anything that happened before that version".
* 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. * Make "git fetch" and "git clone" die() when zero or negative number is given with --depth=$N, for the following reasons: - The --depth option is describe as: ("git clone") ... a 'shallow' clone with a history truncated to the specified number of revisions. ("git fetch") Limit fetching to ancestor-chains not longer than n. It is fairly clear from the above that negative $N does not make any sense. Technically, fetching the commits that were explicitly asked for and not there parents is the only possible ancestor-chain that is not longer than -4, so "git fetch --depth=-4" ought to behave just like "git fetch --depth=0", but you have to be very sick to read the documentation and expect things to work that way. Also there is no way to misread the "git clone" documentation and expect "git clone --depth=-4" to create a history truncated to negative number of revisions. Which means that it is the right thing to do to die() when a negative number is given to --depth for these commands. - As people count from one, the natural way to ask for the tip commit without any history ought to be "--depth=1". Let's declare the current behaviour of "--depth=1" that gives the tip and one commit behind it a bug. Which means that these commands should be updated to die() when zero is given to their --depth option. "Do not give me any history" is inherenty incompatibe with "clone" or "fetch". Because there is no configuration variable "fetch.depth" (or "clone.depth") that forces all your cloned repositories to be shallow, "git clone --depth=0" or "git fetch --depth=0" couldn't have been ways for existing users to ask to defeat any funny configured depth value and clone or fetch everything. When they wanted to clone or fetch everything, they would have just used the command without any "--depth" option instead. Which means that nobody gets hurt if we change these commands to die() when zero is given to their --depth option. * 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). 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. Can people sanity check the reasoning outlined here? Anything I missed? The above outline identifies three concrete tasks that different people can tackle more or less independently, each with updated code, documentation and test: 1. "git fetch --unshallow" that gives a pretty surface on Duy's "--depth=inf"; 2. Making "git fetch" and "git clone" die on "--depth=0" or "--depth=-4"; 3 Updating "upload-pack" to count correctly. I'll refrain from saying "Any takers?" for now. -- 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