Re: git subtree as a solution to partial cloning?

[Avery Pennarun <apenwarr@gmail.com>]

On Mon, May 25, 2009 at 3:21 AM, Asger Ottar Alstrup <asger@area9.dk> 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