Re: Opera release Git-splitter, a sub-modularizing tool for Git

["Yngve Nysaeter Pettersen" <yngve@opera.com>]

On Fri, 21 Dec 2012 16:49:21 +0100, Matthieu Moy  
<Matthieu.Moy@grenoble-inp.fr> wrote:

> "Yngve Nysaeter Pettersen" <yngve@opera.com> writes:
>
>> The split command will create a new repository for all files foo in a
>> folder (path/foo) and their commit history.
>>
>> The replant command reverses that process, re-adding the path prefix
>> for each file. It may be possible to extend that process into one that
>> automatically reintegrates the new commits in the original history,
>> but I never had time to complete that work.
>>
>> I did originally add the "replant" functionality into my version of
>> the git-subtree script, but given the number of commits in the
>> original repository, git-subtree turned out to be inefficient, due to
>> the use of temporary files (tens of thousands of files IIRC).
>>
>> Those problems led to my development of git-splitter in Python
>> (bypassing the problem of temporary files), but just including the
>> functionality I needed, join was not one of those functions.
>
> That still doesn't answer the question: why did you need to write a new
> tool instead of extending git-subtree?

The primary problem with git-subtree was that I ended up with a temporary  
file directory containing 100+K files, which I tracked back to being used  
to manage the commit-to-tree mapping. On Windows, at least, that literally  
slowed down the process to a crawl.

> If one doesn't use "replant", is your tool different from git-subtree?

No, it is not different. However, my tool will use RAM, not diskspace to  
manage information.


-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 96 90 41 51              Fax:    +47 23 69 24 01
********************************************************************