Git Migration Needs YOU!

John Tapsell johnflux at
Tue Mar 2 13:33:28 GMT 2010

On 2 March 2010 13:16, Thiago Macieira <thiago at> wrote:
> Em Terça-feira 02 Março 2010, às 11:29:24, Eike Hein escreveu:
>> > Thiago mentioned that kdepimlibs is a new module, and thus does not need
>> > any work, but that's not true, as all of that code has a long running
>> > and valuable history all the way back to the cvs days. Which was, so
>> > far, retained.
>> Yeah, tracking moves like that, as well as things like apps
>> moving from playground into kdereview and then finally a mo-
>> dule, is why Thiago's old ruleset if woefully incomplete and
>> why writing the rules files is such a mammoth task (and will
>> need the cooperation and collaboration from actual develop-
>> ers on the respective codebases to make certain decisions
>> at times, etc.)
> The old rules file did track moves correctly from playground to review and from
> review to extragear.
> It did not and doesn't intend to track moves from review into the main
> modules. There's a history cut there.
> To do it properly, the entire conversion process needs to be done in two
> phases, which basically means either writing a post-processing tool (my
> "fixups" idea, see mail titled "Braindump: fixups" dated 2008-07-19) or
> refactoring the tool completely.
> As for the kdepim / kdepimlibs split and history tracking, no, that wasn't
> intended either. It will be very hard to continue that in Git, though not
> impossible. It might be possible to graft the kdepim pre-KDE 4 history onto a
> clean kdepimlibs import, so that Git knows where the code came from, so it can
> continue to do the merging.
> In the normal case, I recommend people do not move or rename files if they
> intend to do merges. Git can follow renames, but sometimes it gets lost if
> there are too many files (it's an O(n²) operation, so for 37k files like there
> are in Qt, the operation balloons to 1.3 billion comparisons, unless you
> impose limits)

That's only if you've actually renamed all 37k files in a single commit!

If you do find yourself in a situation where you need to rename
thousands of files at time, _then_ you might want to break your commit
into small commits.


More information about the kde-core-devel mailing list