Re: [PATCH] add --remote option to git-clone.

From: Jakub Narebski <jnareb@gmail.com>
Date: Feb 3, 2007, 09:06 UTC
Message-ID: <eq1j8i$rtv$1@sea.gmane.org>
In-Reply-To: <7vmz3wdjxu.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:

Show 18 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
>> On Thu, 1 Feb 2007, Junio C Hamano wrote:
>> ...
>>> I am not against the general idea of tracking a subset of
>>> branches, but issues include:
>>>
>>> [explains why git-remote is a better place for this]
>>
>> Seeing your patch to git-remote, it feels more natural, too. Especially 
>> since that (or which? :-D) does not give the term "clone" a 
>> Microsoft'esque completely new meaning.
> 
> I did not find anything MS'esque in what MST did in his patch,
> though.  I think it is a reasonable thing to ask for from a
> clone.  For example, if you are coming from CVS or have used
> Cogito, cloning a single branch is not an unusual operation at
> all.

But when we clone whole repository we could have download whole object database of cloned repo as-is (perhaps packing loose objects in smart/git-aware transports).

By the way, there was discussed idea about marking pu-like branches as being rewound (non-fast forwarding) in the config file, and somehow transferring this information for git-clone for it to have '+' for some refspecs. What happened to that idea? Was it abandoned because reflogs are now enabled by default, are protected from pruning, and it is easy to recover from accidental non-fast forward fetch which shouldn't be?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git