From: Rogan Dawes <lists@dawes.za.net>
Date: Tue, 11 Mar 2008 09:07:48 GMT
Subject: Re: [QUESTION] Selective fetch possible?
Message-ID: <47D64BE4.9010009@dawes.za.net>
In-Reply-To: <20080311075053.GQ8410@spearce.org>

Shawn O. Pearce wrote:
> Rogan Dawes <lists@dawes.za.net> wrote:
>> Jakub Narebski wrote:
>>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>>>
>>>> Filippo Zangheri <filippo.zangheri@yahoo.it> wrote:
>>>>> Is it possible to git-fetch only a portion of the tree
>>>>> of the specified repository, say, fetch only one directory or a
>>>>> subset of files matching some regular expression?
>>> The problem is twofold, as far as I understand it.  First, what to do
>>> if there is merge conflicts outside checked out (selected) directory?
>> This is something that has been repeated many times, and I fail to see 
>> how it can be an issue. How can there be a conflict in a directory that 
>> is not, and never has been, checked out, and therefore cannot have been 
>> modified?
> 
> Given two branches:
> 
> 	code
> 	docs
> 
> and the code people checkout the "src/" subdirectory and the docs
> people checkout the "Documentation/" subdirectory, and they *only*
> every work in that subdirectory, things are fine.
> 
> Until one day some developer also checks out "Documentation/" and
> fixes something in the documentation as part of the same commit
> that makes a code change.  The push this to the code branch.
> 
> Someday in the future a documentation writer merges the code branch
> over to the docs branch, "just keeping it current".
> 
> Now there arises a possiblity of a merge conflict in a part of the
> tree that you do not have checked out.
> 
> 
> If you want to say "don't ever modify stuff outside of your branch's
> purpose" then why aren't you just using submodules (one for docs and
> one for code) and using a supermodule to tie everything together into
> a "release package"?

Ok, fair enough. Thanks for the example.

I think that one should not *expect* to be able to complete merges with 
only a partial checkout, though. It *may* work in cases where there are 
no conflicts, but I think it would be a perfectly valid error path to 
fail if there is a conflicting merge in a part of the tree that has not 
been checked out.

So, for a user working on partial trees, they would be able to modify 
their partial tree, and check in their changes, but merges would have to 
be done by someone with a complete checkout. For the given examples 
where partial trees make sense (documentation workers), this seems like 
a reasonable compromise.

>>> Second, how to make repository contain only relevant objects: git in
>>> many places assumes full connectivity, and that if it has an object it
>>> hass all objects depending on it.
>>>
>> Yes, this is the big problem as I see it.
> 
> This is easy enough that if the above problem could be resolved
> sufficiently to the git gurus' satisfaction you would be able
> to get some advice on how to solve it.  Its not difficult, just
> damn annoying.  We already do it (to some extent) with grafts and
> shallow clones.

How's my suggestion above?

Rogan