On Mon, May 25, 2009 at 3:21 AM, Asger Ottar Alstrup <asger@xxxxxxxx> wrote: > I am considering different ways to get git to handle repositories with very > big files in a setup where partial clone is required, and it seems git > subtree might be a part of the solution. Well, that wasn't really what it was originally made for... but perhaps. > Does git subtree support splitting at the file level, or only at directory > level? Currently only at the directory level. In theory, there's nothing stopping us from working with any subset of files... but it's really much simpler this way (both to code and to explain) so I'd much rather leave it as is. Can you reorganize your tree so that you divide the needed files into different subdirectories? > Also, how are conflicts handled when you subtree merge changes back > to the master? 'git subtree split' generates a new commit history on top of the *most recently merged* commit from the subproject. To merge back into the subproject, you would take that newly-generated commit and do the usual "git merge". (ie. you'll have to check out the branch and merge it as usual) Alternatively, you could 'git subtree pull' the subproject first, resolve the conflicts there, and 'git subtree split' after that; in such a case, the newly-generated commit would be a fast-forward from the original subproject's HEAD, so it would be okay to push right away without switching branches first. (Someone else suggested that we add a 'git subtree push' command to make the split-then-push sequence nice and obvious; I think that's a good idea and pretty easy.) > Can the > reduced split repositories reuse pack files from the original repository? Yes, all the tree and blob objects are identical between the two repositories (except that the superproject has more of them, of course). Have fun, Avery -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html