Yngve Nysaeter Pettersen venit, vidit, dixit 21.12.2012 21:13: > On Fri, 21 Dec 2012 16:49:21 +0100, Matthieu Moy > <matthieu....@grenoble-inp.fr> wrote: > >> "Yngve Nysaeter Pettersen" <yn...@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.
That is some valuable input. It can help improve git-subtree for Windows users, or replace it by something else. Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
