Re: [PATCH] rev-list: add "--full-objects" flag.

From: Eric W. Biederman <ebiederm@xmission.com>
Date: Jul 12, 2005, 00:44 UTC
Message-ID: <m13bqk26pp.fsf@ebiederm.dsl.xmission.com>
In-Reply-To: <Pine.LNX.4.58.0507110928070.17536@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 14 quoted lines

> On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>> 
>> I guess I was expecting to pull from one tree into another unrelated
>> tree.  Getting a tree with two heads and then be able to merge them
>> together.
>
> You can do it, but you have to do it by hand. It's a valid operation, but 
> it's not an operation I want people to do by mistake, so it's not 
> something the trivial helper scripts help with.
>
> The way to do it by hand is to just use something stupid that doesn't
> understand what it's doing anyway, and just copy the files over. "cp -a" 
> or "rsync" works fine. Then just do "git resolve" by hand. It's not very 
> hard at all, but it's definitely something that should be a special case.

Ok.  Only the dumb methods are allowed.

Show 10 quoted lines

>> A couple of questions.
>> 
>> 1) Does git-clone-script when packed copy the entire repository
>>    or just take a couple of slices of the tree where you have
>>    references?
>
> It only gets the objects needed for the references, nothing more.
>
> So if you only get one branch, it will leave the objects that are specific 
> to other branches alone.

Hmm. As I recall reading the code it grabs everything that is in .git/refs/*. So I would actually expect it to grab all of the branches. My real question was different. With a clone it appears to just get the objects used to compose a tree object, but none of the history available by looking at the commit parents is obtained. Not at all what I would expect for an operation named clone.

Eric