git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [QUESTION] Selective fetch possible?

From
RDRogan Dawes <lists@dawes.za.net>
Date
Mar 11, 2008, 09:07 UTC
Message-ID
<47D64BE4.9010009@dawes.za.net>
In-Reply-To
<20080311075053.GQ8410@spearce.org>
Shawn O. Pearce wrote:
Show 39 quoted lines
> 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.

Show 11 quoted lines
>>> 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
Previous: Shawn O. PearceNext: Filippo Zangheri
Message 6 of 7 in “[QUESTION] Selective fetch possible?”
  1. Filippo ZangheriMar 10, 2008
  2. Shawn O. PearceMar 10, 2008
  3. Jakub NarebskiMar 10, 2008
  4. Rogan DawesMar 11, 2008
  5. Shawn O. PearceMar 11, 2008
  6. Rogan DawesMar 11, 2008
  7. Filippo ZangheriMar 11, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.