On 01/09/2013 03:53 AM, Junio C Hamano wrote:
> 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.
On Wed, Jan 9, 2013 at 9:53 AM, Junio C Hamano wrote:
> * Make "git fetch" and "git clone" die() when zero or negative
>number is given with --depth=$N, for the following reasons:
>...
For Stefan when you update the patch. If "git fetch --depth=0" is
considered invalid too as Junio outli
On Wed, Jan 9, 2013 at 12:19 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Wed, Jan 9, 2013 at 9:53 AM, Junio C Hamano wrote:
>> ...
>>> * 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")
Duy Nguyen writes:
> On Wed, Jan 9, 2013 at 9:53 AM, Junio C Hamano wrote:
> ...
>> * 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
>>t
On Wed, Jan 9, 2013 at 9:53 AM, Junio C Hamano 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 b
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 explici
6 matches
Mail list logo
