diff options
| author | Ulrich Spörlein <uqs@spoerlein.net> | 2012-11-23 10:32:35 +0100 |
|---|---|---|
| committer | Torgny Nyblom <nyblom@kde.org> | 2012-11-26 14:59:48 +0100 |
| commit | 123433669f472eb7eee31f62ea1601f545a31587 (patch) | |
| tree | ec43f00249605d0e8db15fecc8d574171a4ccfc9 /src/ruleparser.cpp | |
| parent | 8314eb23393db323b4bb5e34a9ad4e8ebc4014fb (diff) | |
| download | svn2git-123433669f472eb7eee31f62ea1601f545a31587.tar svn2git-123433669f472eb7eee31f62ea1601f545a31587.tar.gz svn2git-123433669f472eb7eee31f62ea1601f545a31587.tar.bz2 svn2git-123433669f472eb7eee31f62ea1601f545a31587.tar.xz svn2git-123433669f472eb7eee31f62ea1601f545a31587.zip | |
Make conversion runs deterministic by sorting what's returned via hash from the SVN API.
An SVN commit spanning multiple paths that shall be turned into
multiple branches in git would result in the git commits to be fed into
git fast-import in arbitrary order. This is problematic for merge
commits, as it means the list of parent commits for the merge commit
will have an arbitrary order. Fix this by always handling the paths in
an SVN commit in order. This makes svn2git conversion runs reproducible.
Unfortunately, commits where paths have been removed and added again,
might no longer be handled correctly. I haven't found such a case in the
FreeBSD repository however.
This is IHMO a bug in git, but it all hinges on semantics like list of
parents vs. set of parents and how you define a hash on a set of objects
that have no natural order.
Diffstat (limited to 'src/ruleparser.cpp')
0 files changed, 0 insertions, 0 deletions