Giter Site home page Giter Site logo

freebsd / git_conv Goto Github PK

View Code? Open in Web Editor NEW
12.0 17.0 14.0 244.2 MB

Scripts used for the svn to git conversion of the FreeBSD repositories

Dockerfile 0.06% QMake 0.22% C++ 36.40% Shell 16.14% Perl 25.07% Makefile 0.25% C 20.27% Yacc 0.75% Lex 0.83%

git_conv's Introduction

Subversion to Git conversion scripts for the FreeBSD project

These are the scripts and data used for the svn to git conversion of the FreeBSD repositories. Your help is requested in making sure the produced result is an acceptable representation of the current SVN repository. Fixing some few historical glitches are in scope if the effort is reasonable. Please let us know what you find.

Errata

  1. An oversight in the vendor branches resulted in the history of the ipfilter kernel parts being chopped in two. There is vendor/ipfilter-sys for the newer commits and vendor/ipfilter-sys-old for the older commits. Both of those heads were merged into main with commit bfc88dcbf709 or SVN r255332. A git replace object was put into place to join these two histories, but you need to fetch refs/replace/ to make that visible. A fixed ruleset is in the errata_1 branch of this repo, see also https://github.com/freebsd/git_conv/issues

  2. Somewhere along the conversion, the --identity-domain flag was dropped, resulting in some author/committer emails ending in "@localhost". Furthermore, a missing author map entry was made non-fatal in the upstream code, and this was missed, resulting in a few commits not having a full name entry as well. This affects 1 commit in the src repo by "davidg" and a bunch of them in the doc repo:

    % git log --all | egrep "^Author: [a-z]" | sort | uniq -c
      1 Author: bean <bean@localhost>
      6 Author: davidg <davidg@localhost>
      3 Author: jmc <jmc@localhost>
    145 Author: nsj <nsj@localhost>
      1 Author: skynyrd <skynyrd@localhost>
      1 Author: svn2git <[email protected]>
      7 Author: viny <viny@localhost>
     28 Author: www <www@localhost>
    

Gimme the repo!

git clone https://git.freebsd.org/src.git && cd src
git config --add remote.origin.fetch '+refs/notes/*:refs/notes/*'
git config --add remote.origin.fetch '+refs/replace/*:refs/replace/*'
git fetch

Same for the doc and ports repos. You can expect some things to be different. Most importantly you should check whether branch and mergepoints (especially for vendor branches, but also project branches) are there and make sense.

Neither user or projects branches are "visible" by default. backups refs are deleted branches and cvs2svn contains some of the detritus left over from the CVS days and the cvs2svn conversion. The internal namespace for now only has the access and mentors file, detailing when people got their various commit bits. We will likely move these to a combined repo for doc, src, and ports.

git config --add remote.origin.fetch '+refs/projects/*:refs/projects/*'
git config --add remote.origin.fetch '+refs/user/*:refs/user/*'
git config --add remote.origin.fetch '+refs/backups/*:refs/backups/*'
git config --add remote.origin.fetch '+refs/cvs2svn/*:refs/cvs2svn/*'
git config --add remote.origin.fetch '+refs/internal/*:refs/internal/*'
git fetch

Note that internal, projects and user branches also exist for the doc repo and ports has projects and releng as well. cvs2svn and backups are exclusive to the src repo though.

  • user/ branches are never merged back into master
  • MFHs into user/ or projects/ branches are just cherry-picks to keep git log --graph somewhat readable and as merges wouldn't convey any useful information, really.
  • vendor tags were never flattened post-creation, as that would advance them off of the mainline branch and make them invisible to a simple git log
  • release/1.0_cvs et al. are snapshots of the checked out CVS source code, including expanded $Id$ tags.
  • no other keywords are expanded
  • various vendor-foo suffixes have been collapsed into 1 vendor namespace, except for a few vendors where merging the userland and kernel bits is not straightforward due to how they interleave with the merge and branch history. This is what also caused Errata 1.
  • some branches have their history "extended", that is, commits under the cvs2svn area were properly attached.
  • ... and most of these commits have actually been inlined directly into the mainline tree to keep the history more "linear" and associate the commit with the original author and commit message.

How to analyze the results

Here are some tips that were deemed useful in making sense of resulting history. Please add a "graph notes log" alias to your .gitconfig:

[alias]
  gnlog = log --graph --pretty=format:'%Cred%h %C(green)%t %Creset %C(red)%ad %Creset-%C(yellow)%d%Creset %s %n      %N %-GG' --date=short

Show the full tree of a vendor area

git gnlog `git show-ref|grep vendor/sendmail|cut -d" " -f1`

Find a certain SVN revision on master

git show -p `git log --format=%h --notes --grep=revision=294706$`

Show how/where/when a vendor branch was merged into master over time

git gnlog vendor/zstd/dist master

(but you'll need to search in the massive output for where the vendor branch is being merged, if you know a better way to represent this, please let us know!)

Look for commits with more than 5 parents and log them

git log --format='%H %P' --all|awk '{if (NF > 5) { print NF " " $0}}'|sort -rn|cut -d" " -f2|xargs -n1 -I% git snlog -n 1 %

If you want to run the conversion yourself and play with the rules, read on.

Required Software

pkg install qt5-qmake qt5-core subversion git shlock

(for Debian: apt install qt5-qmake qtbase5-dev libapr1-dev libsvn-dev subversion git shlock)

A patched copy of svn2git aka. svn-all-fast-export has been added to this repo using: git subtree add --squash --prefix svn2git https://github.com/freebsd/svn2git master

A copy of parsecvs has been added using: git subtree add --squash --prefix parsecvs https://github.com/BartMassey/parsecvs master

cd svn2git && qmake && make && cd ..
cd parsecvs && make && cd ..

Setup

You'll need to download a seed of the SVN repository dump (it takes weeks to bootstrap otherwise). NOTE: Depending on the mirror nearest to you, the metadata of this mirrors is actually off by several seconds for several of the commits and is also sometimes missing the author. Furthermore, using the one-true SVN repo as the source will drop all forced commits. Don't ask me why this happens.

fetch https://download.freebsd.org/ftp/development/subversion/svnmirror-base-r358354.tar.xz
fetch https://download.freebsd.org/ftp/development/subversion/svnmirror-ports-r527184.tar.xz
fetch https://download.freebsd.org/ftp/development/subversion/svnmirror-doc-r53937.tar.xz
tar xf svnmirror-base-r358354.tar.xz
tar xf svnmirror-doc-r53937.tar.xz
tar xf svnmirror-ports-r527184.tar.xz

Conversion runs

  • (optional:) fetch the current SVN state using ./svnmir.sh -1
  • convert either base, doc, or ports using ./git_conv { base | doc | ports }

Additional runs of svnmir.sh or git_conv will run incrementally.

NOTE: This is not longer true, while it works fine for git version 2.24 and 2.25, at least version 2.27 will cause git-fast-import upon reading the marks file to eat up all RAM and eventually crash with out of memory.

On on moderately fast system with an SSD and/or enough RAM for the buffer cache, this should take about 2h to finish for src and will produce about 10GiB of intermediate data. The final src repo size should be around 1.7GiB.

Re-runs will re-use the previous packfiles and will likely be faster. Currently src finishes in about 1 hour, doc in 2 minutes and ports in 45 minutes.

What you get

  • src will have: master, stable/N, releng/N, release/N.M, vendor/*
  • doc will have: master, release/N.M
  • ports will have: master, branches/YYYYQx

In the future, project branches will be individual forks of the repos. Hosted either on GitHub, GitLab or our own infrastructure.

Further information and documentation can be found on the Wiki sites at https://github.com/freebsd/git_conv/wiki

For the curious

blaming the whole project takes about a day of wall clock time using this naive approach:

git ls-tree -r --name-only -z HEAD|xargs -0n1 git blame -e --line-porcelain | sed -n 's/^author-mail //p' | sort -f | uniq -ic | sort -nr

It only blames the current state of the repo, not all of history, mind you. After several hairy fixes, this could be reduced from more than 6000 lines down to just 182 lines that are now falsely attributed to author "cvs2svn". The files are gnu/usr.bin/grep/AUTHORS and a few under usr.sbin/ppp.

License

The included svn2git is GPLv3; see svn2git/LICENSE. The included parsecvs is GPLv2; see parsecvs/COPYING. The scripts and configuration files are licensed under CC0.

git_conv's People

Contributors

bdragon28 avatar bsdimp avatar dspinellis avatar emaste avatar glebius avatar lwhsu avatar uqs avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

git_conv's Issues

How to handle SVN tags as git branches (or tags)?

See this for the svn2git authors take on SVN tags as git tags:
https://github.com/svn-all-fast-export/svn2git/blob/master/samples/merged-branches-tags.rules

What happens during the conversion is that I end up with some garbage
(?) tags, and the SVN tags are actually branches:

% git tag
backups/projects/flavors@441387
backups/projects/rework-dependency-registration@438064
backups/projects/targets-when-needed@438063
backups/tags/RELEASE_11_0_0@421515
backups/tags/RELEASE_8_4_0@315832
backups/tags/RELEASE_9_3_0@358866
backups/tags/RELEASE_9_3_0@359466

I think these are created when a branch gets deleted, so that it's
still reachable after a git gc run, hence the recording of which svn
rev they got deleted.

These are the git branches I get:

% git branch|grep RELENG_2
branches/RELENG_2_1_0
branches/RELENG_2_2
tags/RELENG_2_0_5
tags/RELENG_2_0_5_ALPHA
tags/RELENG_2_0_5_BP
tags/RELENG_2_0_5_RELEASE
tags/RELENG_2_1_0_BP
tags/RELENG_2_1_0_RELEASE
tags/RELENG_2_1_5_RELEASE
tags/RELENG_2_1_6_1_RELEASE
tags/RELENG_2_1_6_RELEASE
tags/RELENG_2_1_7_RELEASE
tags/RELENG_2_2_0_RELEASE
tags/RELENG_2_2_1_RELEASE
tags/RELENG_2_2_2_RELEASE
tags/RELENG_2_2_5_RELEASE
tags/RELENG_2_2_6_RELEASE
tags/RELENG_2_2_7_RELEASE
tags/RELENG_2_2_8_RELEASE
tags/RELENG_2_2_BP

and I can't push them with git push --tags, but I can push them after
adding the refs like so:
% cat config
[core]
repositoryformatversion = 0
filemode = true
bare = true
autocrlf = false
ignorecase = false
[push]
default = matching
[remote "bapt"]
url = ssh://[email protected]:1022/ports
fetch = +refs/heads/:refs/remotes/bapt/
push = +refs/heads/master:refs/heads/master
push = +refs/heads/projects/:refs/heads/projects/
push = +refs/heads/branches/:refs/heads/branches/
push = +refs/heads/tags/:refs/tags/
push = +refs/notes/:refs/notes/

They now show up on here https://git.etoilebsd.net/ports/ as tags, but
I'm not sure whether they are actually git tags or not.

What's your thinking here. Do we want to keep them as branches or is
there a way to convert them into proper git tags? (check the commit
which the "branch" points to, then "git tag" them)

svn2git bus error

converting r184379,

(lldb) bt
* thread #1, name = 'svn-all-fast-exp', stop reason = signal SIGBUS: hardware error
  * frame #0: 0x00000008006b6fe7 libQt5Core.so.5`QHashData::nextNode(QHashData::Node*) + 7
    frame #1: 0x000000000023e2a8 svn-all-fast-export`SvnRevision::maybeParseSimpleMergeinfo(int, QSet<mergeinfo>*) [inlined] QHash<mergeinfo, QHashDummyValue>::iterator::operator++(this=<unavailable>) at qhash.h:329:17
    frame #2: 0x000000000023e2a0 svn-all-fast-export`SvnRevision::maybeParseSimpleMergeinfo(int, QSet<mergeinfo>*) [inlined] QSet<mergeinfo>::iterator::operator++(this=<unavailable>) at qset.h:128
    frame #3: 0x000000000023e2a0 svn-all-fast-export`SvnRevision::maybeParseSimpleMergeinfo(this=0x00007fffffffe3a8, revnum=184966, mi_list=0x00007fffffffe328) at svn.cpp:709
    frame #4: 0x0000000000238972 svn-all-fast-export`SvnRevision::prepareTransactions(this=<unavailable>) at svn.cpp:1028:20
    frame #5: 0x0000000000236c53 svn-all-fast-export`SvnPrivate::exportRevision(this=<unavailable>, revnum=184966) at svn.cpp:509:13
    frame #6: 0x00000000002369cc svn-all-fast-export`Svn::exportRevision(this=<unavailable>, revnum=<unavailable>) at svn.cpp:157:15
    frame #7: 0x000000000024f0ed svn-all-fast-export`main(argc=9, argv=<unavailable>) at main.cpp:279:18
    frame #8: 0x0000000000216210 svn-all-fast-export`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1.c:76:7

Create redirector for old svn web links to new git repo

Pointed out by Dan, these sorts of links should continue to work

https://svnweb.freebsd.org/ports/head/graphics/mesa-devel/Makefile?annotate=537860
or
https://svnweb.freebsd.org/ports?view=revision&revision=537860

uqs comments:
So the redirector needs to run:
% git log --format=%H --notes --grep=revision=537860$ master
69116835276115e2dbec1332f2070300e4905d76

and 301 to https://cgit-beta.freebsd.org/ports/commit/?id=69116835276115e2dbec1332f2070300e4905d76 or
https://cgit-beta.freebsd.org/ports/diff/graphics/mesa-devel/Makefile?id=69116835276115e2dbec1332f2070300e4905d76
depending on a file path being present or whatever.

If a plugin in gitolite could do that translation, that would be great.

And Warner notes:
Do we need to track this as an item in our github issues area? We don't really need the redirector until we turn off the current svn web server, which can run indefinitely with a read-only svn repo...

Vendor tag branches are being recorded falsely

No idea what is going on here, but note when 20170608 was imported vs. where the tag is coming from (same for 1.14.2). The contents of the tag are all fine, but the branchpoint is messed up. This affects numerous vendor tags

* 75b6c55cb02a - Import mandoc 1.14.2 
|       svn path=/vendor/mdocml/dist/; revision=321807
|  
| * ddffdf6064c6 - (vendor/mandoc/1.14.2) Tag import of mandoc 1.14.2 
|/        svn path=/vendor/mdocml/1.14.2/; revision=321808
|    
* 7ad21139cd51 - Import mandoc 2017-06-08 
|       svn path=/vendor/mdocml/dist/; revision=319715
|  
* 6cae2c9f93ec - Import mandoc 1.14.1 
|       svn path=/vendor/mdocml/dist/; revision=314095
|  
* 696a89ee8dc1 - Import mandoc 1.4.1rc2 
|       svn path=/vendor/mdocml/dist/; revision=313956
|  
| * b2877366839f - (vendor/mandoc/20170608) tag import of mandoc snapshot 20170608 
|/        svn path=/vendor/mdocml/20170608/; revision=319716
|    
| * 4483a76c09db - (vendor/mandoc/1.4.1) Tag import of mandoc 1.4.1 
|/        svn path=/vendor/mdocml/1.4.1/; revision=314096
|    
| * 1d298b9caca1 - (vendor/mandoc/1.4.1rc2) Tag import of mandoc 1.4.1rc2 
|/        svn path=/vendor/mdocml/1.4.1rc2/; revision=313957
|    
* ef7476572c9a - Import mandoc cvs snapshot 20170121 (pre 1.14) 
|       svn path=/vendor/mdocml/dist/; revision=312591
|  

The converter logs these down like so:

progress SVN r321807 branch vendor/mandoc/dist = :321407                                                                                                               
progress SVN r321808 branch vendor/mandoc/1.14.2 = :319394 # from branch vendor/mandoc/dist at r321806 => r319715
progress SVN r321808 branch vendor/mandoc/1.14.2 = :321408

where it messes up the "from" of the branch. It's also in the regular output:

Exporting revision 321807 ................................................................................... 83 modifications from SVN /vendor/mdocml/dist/ to freebsd-base.git/vendor/mandoc/dist done
Exporting revision 321808     /vendor/mdocml/1.14.2 was copied from /vendor/mdocml/dist rev 321806
.freebsd-base.git : branch vendor/mandoc/1.14.2 is branching from vendor/mandoc/dist
Creating branch: "vendor/mandoc/1.14.2" from "vendor/mandoc/dist" ( 321806 "from branch vendor/mandoc/dist at r321806 => r319715" )

This is coming from FastImportRepository::markFrom in repository.cpp

Make the release tags have the matching source code of the release ISOs

Should be super easy to do, given the src copies we have under http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/

What makes it easy is that the release tags are "leaves", so we don't need to rewrite any history, just simply create those tags and point their parent commit to the real branch point.

It gets complicated a bit by us using annotated tags, so we don't readily have a commit we can hook this off of, but we can just re-use the commit log of whatever created the tag, though we need to add a "this commit was manufactured ..." blurb.

Examine ability to connect the repository with history of historic Unix releases

Being able to run git blame and git log back to historic (e.g. pre-FreeFBSD 1.0) releases can be useful. However, directly including such releases in the repo is problematic:

  • A lot of old information is available as snapshots or file-level commits rather than as atomic commits
  • Uncertainty on how snapshots are to be interpreted (e.g. with regard to authors) means that
    the historic releases can change as their interpretation becomes more accurate, affecting the
    SHAs of newer commits
  • The usefulness of having access to past revisions decreases as these become older

Using git replace it might be able to link historic releases (e.g. through the Unix history repository) without affecting the main repository's stability and integrity.

git hooks

What sort of hooks do we need installed?

  • disallowing merge commits?
  • how to prevent people from faking the committer string to something else?
  • enforce that committer uses @FreeBSD.org address?
  • ?

Address subtree project branches

We've handled project/user branches in svn in two ways:

  1. Copying the entire tree to a working branch, making changes, merging back
  2. Copying only some subtree, making changes, merging back to that subtree in head

2 is less common, but there are some instances such as:

r276329 /usr/nwhitehorn/kboot/
r300828 /projects/bhyve_graphics

These cause some grief in the git conversion, in a couple of ways. First, they appear to be a change that moves a few files and deletes the rest of the tree. Second, they confuse "git subtree split", which sees the change as affecting a subtree unrelated to the working branch.

More information at: https://lists.freebsd.org/pipermail/freebsd-git/2019-November/000218.html
Description of the "subtree split" issue: https://lore.kernel.org/git/CAPyFy2AsmaxU-BDf_teZJE5hiaVpTSZc8fftnuXPb_4-j7j5Fw@mail.gmail.com/

I believe we can just skip these branch creation commits entirely, assuming that they copied the subtree to the project/user branch unchanged.

pull admin branch into separate repo

We want to pull the src/doc/ports access files (and mentors, possibly others?) into a single repo so we can get rid of the internal/ ref and have just 1 branch to deal with, instead of 3.

The question is, what do we need from the CVS/SVN days and how to organize it?

Currently we have roughly 3x:

% cd freebsd-base.git
% git ls-tree -r internal/admin
100644 blob ccca99be17bc211ffd19953e3ce5745e6948fc6a    access
100644 blob 16aaaaa4a17481cc6a1fae3cd7c3611650852127    access.doc
100644 blob 09d7a232a7eaef023943ef207ee77f2a7460f512    mentors

In the early days there was a single access file, and we should be able to easily recreate that in our single branch and later on move out src and ports. But what shall the branch look like? Li-Wen, what are the files we need, and where should they be?

Proposal (not all files might exist):

access.{src,doc,ports}
access  (which is later deleted when the above 3 files spring into existence, alternative: name it access.src from the start, or have access{,.doc,.ports} instead?
mentors.{src,doc,ports}   (do we really want to split this? I think not ...)

Anything else we'd need from svnadmin?

Fix $Id$ tags to match the actual CVS revision

Basically infeasible, but currently SVN has the $Id$ off-by-one, meaning the $Id$ tag being committed in revision N is actually the content of N-1. It would be sweet to fix this up, otherwise future archaeologists will scratch their heads.

Example in ports:

% git log -p -- databases/db/Makefile
...
commit 6dca55ed122f25b1bbe40274341eac760a75bdba
Author: James FitzGibbon <[email protected]>
Date:   1997-09-05 20:22:12 +0000

    Upgrade to v2.2.6
    Submitted by:   Josh Tiefenbach <[email protected]>

Notes:
    svn path=/head/; revision=7783

diff --git a/databases/db/Makefile b/databases/db/Makefile
index 1d11be7da943..c8764c99ac7d 100644
--- a/databases/db/Makefile
+++ b/databases/db/Makefile
@@ -1,12 +1,12 @@
 # ports collection makefile for:       Berkeley DB
-# Version required:                    v2.1.0
+# Version required:                    v2.2.6
 # Date created:                                12 Jun 1997
 # Whom:                                        Josh Tiefenbach <[email protected]>
 #
-# $Id:$
+# $Id: Makefile,v 1.1.1.1 1997/06/13 17:54:36 jfitz Exp $
 #
...
commit 1f93dcfb8c1e47b7259ce47c4e1216856405eb92
Author: James FitzGibbon <[email protected]>
Date:   1997-06-13 17:54:36 +0000

    Import of Berkely DB 2.0
    Submitted by:   Josh Tiefenbach <[email protected]>

Notes:
    svn path=/head/; revision=6913

diff --git a/databases/db/Makefile b/databases/db/Makefile
new file mode 100644
index 000000000000..1d11be7da943
--- /dev/null
+++ b/databases/db/Makefile
@@ -0,0 +1,27 @@
+# ports collection makefile for:       Berkeley DB
+# Version required:                    v2.1.0
+# Date created:                                12 Jun 1997
+# Whom:                                        Josh Tiefenbach <[email protected]>
+#
+# $Id:$
...

Note how the initial commit has an empty Id, and the second commit has the Id date of the first commit.

I have no idea whether this expansion was done by cvs2svn, or whether it is purely a byproduct of the working tree at the time of the CVS commit.

There should be a simple heuristic to take all the diffs to Ids, check their previous commit for its date/time and if there's a match, hoist it over.

Who's going to write that script though?

teach cgit to handle tags better

The problem is that it prepends refs/tags/ to a tag ref unconditionally, so going from
https://cgit-beta.freebsd.org/src/log/?h=refs/vendor/xz/dist
to
https://cgit-beta.freebsd.org/src/tag/?h=refs/vendor/xz/5.2.5
results in a "bad tag reference"

The problematic code is here: https://sourcegraph.com/github.com/zx2c4/cgit@adcc4f822fe11836e5f942fc1ae0f00db4eb8d5f/-/blob/ui-tag.c#L50-54
and from the looks it just needs a conditional to leave the tag alone, if it starts with "refs/" already.

Will need to find out how to submit a patch to cgit over the holidays ...

@lwhsu FYI only.

Stash vendor, user, projects branches so that they don't get pulled by default.

A plain git clone will slurp in everything, including

  • vendor tags (regular users shouldn't care about these)
  • backup tags for deleted cvs2svn branches (we need to stash them somewhere else)
  • vendor branches (again, shouldn't be pulled by regular users)
  • releng, ditto
  • projects, ditto
  • user, ditto

They should all be there for interested parties to download, but not come by default.

Not sure what is possible here, we might have to tell people to only clone master and refs/notes (though the SVN notes will quickly become useless over time as people will refer to git commit hashes and not SVN revisions in their commit logs).

keep cgit-beta hashes stable for at least 2 weeks at a time

Discussed during the 2020-07-07 call. We would like to keep hashes stable for 2 week periods at a time (e.g. if hashes will change because we tweak the converter, do that only once every 2 weeks). This will allow folks to experiment with work on based on cgit-beta without having to deal with surprise hash changes.

errata #1 ipfilter-sys was incorrectly converted

Due to various shuffles an oversight in the rules led to the ipfilter vendor branch for the kernel parts to be split in 2 distinct branches that are merged (together with userland) in r255332.

This was discovered too late in the conversion and has been sort of patched with a replace graft. This will however be only visible to users that explicitly fetch the grafts.

The good news is that the vendor/ipfilter-sys branch is the newer one, so at least the latest and greatest is visible.

analyze the cases of "too many merge parents"

svn2git limits the number of parents to 16, which I think is a git limitation.

The revisions are:

Exporting revision 215417 .............copy from branch "master" to branch "user/jchandra/8-stable-mips" @rev 204548
...
WARN: too many merge parents
 867 modifications from SVN /user/jchandra/8-stable-mips/ to freebsd-base.git/user/jchandra/8-stable-mips done
Exporting revision 239154 .................................    /projects/armv6/cddl/contrib/dtracetoolkit/Apps was copied from /head/cddl/contrib/dtracetoolkit/Apps rev 235381
...
WARN: too many merge parents
 7513 modifications from SVN /projects/armv6/ to freebsd-base.git/projects/armv6 done
Exporting revision 262234 .......    /projects/pf/head/bin/date/tests was copied from /head/bin/date/tests rev 259213
...
WARN: too many merge parents
 7818 modifications from SVN /projects/pf/head/ to freebsd-base.git/projects/pf/head done

errata #2 identity-domain got dropped and some commits are done by foo@localhost

affects only 1 commit in src, but a bunch of them in docs

src:

% git log --all | egrep "^Author: [a-z]" | sort | uniq -c
1694 Author: cvs2svn <[email protected]>
   1 Author: davidg <davidg>
   4 Author: svn2git <[email protected]>

doc:

% git log --all | egrep "^Author: [a-z]" | sort | uniq -c
   1 Author: bean <bean@localhost>
   6 Author: davidg <davidg@localhost>
   3 Author: jmc <jmc@localhost>
 145 Author: nsj <nsj@localhost>
   1 Author: skynyrd <skynyrd@localhost>
   1 Author: svn2git <[email protected]>
   7 Author: viny <viny@localhost>
  28 Author: www <www@localhost>

The svn2git commits are the "notes" commits and are intentional, and the cvs2svn schmutz can't be helped.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.