I'm interested in getting a fetch tip commit only feature into git, I'll
probably look into creating a patch for this.
> >>> Sounds buggy. Would anything break if we were to make --depth=1 mean
> >>> "1 deep, including the tip commit"?
> >> As long as we do not change the meaning of the "shallow" count going
> >> over the wire (i.e. the number we receive from the user will be
> >> fudged, so that user's "depth 1" that used to mean "the tip and one
> >> behind it" is expressed as "depth 2" at the end-user level, and we
> >> send over the wire the number that corresponded to the old "depth
> >> 1"), I do not think anything will break, and then --depth=0 may
> >> magically start meaning "only the tip; its immediate parents will
> >> not be transferred and recorded as the shallow boundary in the
> >> receiving repository".
> > I'd rather we reserve 0 for unlimited fetch, something we haven't done
> > so far . And because "unlimited clone" with --depth does not make
> > sense, --depth=0 should be rejected by git-clone.
> I actually was thinking about changing --depth=1 to mean "the tip,
> with zero commits behind it" (and that was consistent with my
> description of "fudging"), but ended up saying "--depth=0" by
> mistake. I too think "--depth=0" or "--depth<0" does not make
> sense, so we are in agreement.
Did you consider how to implement this? Looking at the code, it seems
the "deepen" parameter in the wire protocol now means:
- 0: Do not change anything about the shallowness (i.e., fetch
everything from the shallow root to the tip).
- > 0: Create new shallow commits at depth commits below the tip (so
depth == 1 means tip and one below).
- INFINITE_DEPTH (0x7fffffff): Remove all shallowness and fetch
Given this, I'm not sure how one can express "fetch the tip and nothing
below that", since depth == 0 already has a different meaning.
Of course, one could using depth == 1 in this case to receive two
commits and then drop one, but this would seem a bit pointless to me
(especially if the commit below the tip is very different from the tip
leading to a lot of useless data transfer).
Or did I misunderstand something here?
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