Git Migration Needs YOU!

[Thiago Macieira]

Em Terça-feira 02 Março 2010, às 14:33:28, John Tapsell escreveu:
> On 2 March 2010 13:16, Thiago Macieira <thiago at kde.org> 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.

Not really. This is not exactly about the renaming commits, though that does 
help.

The biggest problem is that when you merge an old tree like 3.5 into a newer 
tree like 4.4, you have something like Dirk once explained for Qt releases:
	-everything +everything

Especially if you've moved *all* files, which is nearly the case here.

In any case, to help Git out, when moving files, it's recommended to move in 
one commit, without code changes, then apply code changes in another. That 
way, Git figures out it was a move because the SHA-1 of each file is exactly the 
same.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100302/066d262a/attachment.sig>