Re: [QUESTION] Selective fetch possible?
- From
- Rogan 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