| | 316 | Git doesn't handle file renames well. Here's a script to demonstrate the problem: |
| | 317 | |
| | 318 | {{{ |
| | 319 | # Demonstrates problem with git's cherry picking not commuting around |
| | 320 | # file renmaes. |
| | 321 | |
| | 322 | rm -rf repo1 repo2 |
| | 323 | |
| | 324 | mkdir repo1 |
| | 325 | cd repo1 |
| | 326 | git init |
| | 327 | printf "b\nd\n" >file |
| | 328 | git-add file |
| | 329 | git-status |
| | 330 | git-commit -m "bd" |
| | 331 | |
| | 332 | cd .. |
| | 333 | git clone repo1 repo2 |
| | 334 | |
| | 335 | cd repo1 |
| | 336 | git mv file file1 |
| | 337 | git commit -m move |
| | 338 | printf "a\nb\nd\ne\n" >file1 |
| | 339 | git commit -m "abde" file1 |
| | 340 | printf "a\nb\nc\nd\ne\n" >file1 |
| | 341 | git commit -m "abcde" file1 |
| | 342 | |
| | 343 | cd ../repo2 |
| | 344 | git remote add -f repo1 ../repo1 |
| | 345 | git cherry-pick repo1/master |
| | 346 | # cherry-picks the most recent change from repo1 |
| | 347 | # BANG!!! |
| | 348 | }}} |
| | 349 | |
| | 350 | Apparently git didn't realise that "file" had been renamed to "file1" in one branch, because its contents had also changed sufficiently. In fact, if you add enough other stuff to the file so that both versions are similar, then the merge works, which is deeply worrying. |
| | 351 | |
| | 352 | This goes wrong with git version 1.5.2.5. I wouldn't be surprised if other versions work, but the underlying issue is that git doesn't store information about file and directory renames, and has to rely on heuristics to recover the information when necessary. Converting a darcs repo into a git repo is a lossy conversion - it discards information about renames. |
| | 353 | |
| | 354 | |