| 1 |
On 03/26/10 06:23, Sebastian Pipping wrote: |
| 2 |
> Consequences |
| 3 |
> ------------ |
| 4 |
> So Git relies on the existence of merge commits to detect what has been |
| 5 |
> merged already. Creating all these merge commits is a tough job for a |
| 6 |
> conversion tool (like svn2git) as it would have to distinguish between |
| 7 |
> cases where just a few commist have been cherry-picked over and cases |
| 8 |
> where all previous commits have made it over. |
| 9 |
> |
| 10 |
> So the portage Git history does not have merge commits at these points |
| 11 |
> but plain single-parent commits. |
| 12 |
|
| 13 |
I was wondering if this could be something that git-svn can do better |
| 14 |
than svn2git: after all what does git-svn do in these 100 minutes taking |
| 15 |
longer than svn2git? |
| 16 |
|
| 17 |
So I ran a git-svn conversion again but it seems it does no better: |
| 18 |
|
| 19 |
# git cherry -v prefix master | wc -l |
| 20 |
7988 |
| 21 |
|
| 22 |
So that looks like about the same. |
| 23 |
|
| 24 |
|
| 25 |
|
| 26 |
Sebastian |
Archives