[Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

This patch adds scripts to contrib/ to migrate full history of GCC's subversion repository to git.  My hope is that these scripts will finally allow GCC project to migrate to Git.

The result of the conversion is at https://github.com/maxim-kuvyrkov/gcc/branches/all .  Branches with "@rev" suffixes represent branch points.  The conversion is still running, so not all branches may appear right away.

The scripts are not specific to GCC repo and are usable for other projects.  In particular, they should be able to convert downstream GCC svn repos.

The scripts convert svn history branch by branch.  They rely on git-svn on convert individual branches.  Git-svn is a good tool for converting individual branches.  It is, however, either very slow at converting the entire GCC repo, or goes into infinite loop.

There are 3 scripts:

- svn-git-repo.sh: top level script to convert entire repo or a part of it (e.g., branches/),
- svn-list-branches.sh: helper script to output branches and their parents in bottom-up order,
- svn-git-branch.sh: helper script to convert a single branch.

Whenever possible, svn-git-branch.sh uses existing git branches as caches.

What are your questions and comments?

The attached is cleaned up version, which hasn't been fully tested yet; typos and other silly mistakes are likely.  OK to commit after testing?

--
Maxim Kuvyrkov
www.linaro.org



[-- Attachment #2: 0001-Contrib-SVN-Git-conversion-scripts.patch --]
[-- Type: application/octet-stream, Size: 7877 bytes --]

From 3dbfff128c125f9d3307dff1e5b44f8135620f2b Mon Sep 17 00:00:00 2001
From: Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>
Date: Tue, 14 May 2019 13:12:36 +0000
Subject: [PATCH] [Contrib] SVN -> Git conversion scripts

	* svn-git-repo.sh, svn-list-branches.sh, svn-git-branch.sh: New scripts.

Change-Id: I437d70c3bc431261bde5eec29e7207d4ebb0fe01
---
 contrib/svn-git-branch.sh    |  92 +++++++++++++++++++++++++++++
 contrib/svn-git-repo.sh      |  57 ++++++++++++++++++
 contrib/svn-list-branches.sh | 108 +++++++++++++++++++++++++++++++++++
 3 files changed, 257 insertions(+)
 create mode 100755 contrib/svn-git-branch.sh
 create mode 100755 contrib/svn-git-repo.sh
 create mode 100755 contrib/svn-list-branches.sh

diff --git a/contrib/svn-git-branch.sh b/contrib/svn-git-branch.sh
new file mode 100755
index 00000000000..70f8deb0a4f
--- /dev/null
+++ b/contrib/svn-git-branch.sh
@@ -0,0 +1,92 @@
+#!/bin/bash
+
+set -euf -o pipefail
+
+svntop="svn+ssh://gcc.gnu.org/svn/gcc"
+verbose=0
+
+while test $# -gt 0; do
+    case "$1" in
+	--svntop) svntop="$2"; shift ;;
+	--verbose) verbose=$(($verbose+1)) ;;
+	--) shift; break ;;
+	*) break ;;
+    esac
+    shift
+done
+
+info ()
+{
+    if [ $verbose -ge 1 ]; then
+	echo "INFO: $@" >&2
+    fi
+}
+
+if [ $verbose -ge 2 ]; then
+    set -x
+fi
+
+info "converting $@"
+
+spec="$1"
+shift 1
+
+branch=$(echo "$spec" | cut -d@ -f 1)
+rev=$(echo "$spec" | cut -s -d@ -f 2)
+
+for parent in "$@"; do
+    parent_branch=$(echo "$parent" | cut -d@ -f 1)
+    parent_rev=$(echo "$parent" | cut -s -d@ -f 2)
+
+    sha1=$(git rev-parse refs/remotes/svn/$parent)
+    mkdir -p $(dirname .git/refs/remotes/svn/$branch@$parent_rev)
+    echo $sha1 > .git/refs/remotes/svn/$branch@$parent_rev
+done
+
+sha1=""
+for i in origin extra; do
+    if git rev-parse refs/remotes/$i/${branch#branches/} >/dev/null 2>&1; then
+	sha1=$(git rev-parse refs/remotes/$i/${branch#branches/})
+    fi
+done
+
+if [ x"$sha1" != x"" ]; then
+    if ! git rev-parse refs/remotes/cache/$branch >/dev/null 2>&1 \
+	   || [ x"$rev" != x"" ]; then
+	mkdir -p $(dirname .git/refs/remotes/cache/$branch)
+	echo $sha1 > .git/refs/remotes/cache/$branch
+
+	cat >> .git/config <<EOF
+
+[svn-remote "cache-$branch"]
+	url = svn+ssh://gcc.gnu.org/svn/gcc
+	fetch = $branch:refs/remotes/cache/$branch
+EOF
+	git svn fetch --log-window-size=10000 "cache-$branch"
+
+	if [ x"$rev" != x"" ]; then
+	    sha1=$(git svn find-rev --before r$rev refs/remotes/cache/$branch)
+	else
+	    sha1=$(git rev-parse refs/remotes/cache/$branch)
+	fi
+
+	head -n -4 .git/config > .git/newconfig
+	mv .git/newconfig .git/config
+    else
+	sha1=$(git rev-parse refs/remotes/cache/$branch)
+    fi
+
+    mkdir -p $(dirname .git/refs/remotes/svn/$spec)
+    echo $sha1 > .git/refs/remotes/svn/$spec
+fi
+
+cat >> .git/config <<EOF
+
+[svn-remote "$spec"]
+	url = svn+ssh://gcc.gnu.org/svn/gcc
+	fetch = $branch:refs/remotes/svn/$spec
+EOF
+
+git svn fetch ${rev:+-r BASE:$rev} --log-window-size=10000 "$spec"
+head -n -4 .git/config > .git/newconfig
+mv .git/newconfig .git/config
diff --git a/contrib/svn-git-repo.sh b/contrib/svn-git-repo.sh
new file mode 100755
index 00000000000..bdabd079c67
--- /dev/null
+++ b/contrib/svn-git-repo.sh
@@ -0,0 +1,57 @@
+#!/bin/bash
+
+set -euf -o pipefail
+
+branchfile=""
+giturl=https://gcc.gnu.org/git/gcc.git
+reference=""
+repo=""
+svnpaths=()
+svntop=svn+ssh://gcc.gnu.org/svn/gcc
+
+while test $# -gt 0; do
+    case "$1" in
+	--branchfile) branchfile="$2"; shift ;;
+	--giturl) giturl="$2"; shift ;;
+	--reference) reference="$2"; shift ;;
+	--repo) repo="$2"; shift ;;
+	--svnpath) svnpaths+=("$2"); shift ;;
+	--svntop) svntop="$2"; shift ;;
+	--verbose) set -x ;;
+	*) echo "ERROR: wrong argument: $1"; exit 1 ;;
+    esac
+    shift
+done
+
+top=$(cd $(dirname "$0"); pwd)
+
+if [ x"$repo" = x"" ]; then
+    echo "ERROR: no --repo /path/to/repo"
+    exit 1
+elif [ -d "$repo" ]; then
+    echo "ERROR: directory $repo exists"
+    echo "       rename it to $repo.bak if it is a good starting point"
+    exit 1
+fi
+
+if [ -d "$repo.bak" ]; then
+    rsync -a --del "$repo.bak/" "$repo/"
+else
+    git clone ${reference:+--reference "$reference"} "$giturl" "$repo"
+    git -C "$repo" config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/extra/*'
+    git -C "$repo" remote update -p
+    rsync -a --del "$repo/" "$repo.bak/"
+fi
+
+(
+    if [ x"$branchfile" = x"" ]; then
+	branchfile=$(mktemp)
+	$top/svn-list-branches.sh --svntop "$svntop" "${svnpaths[@]}" > "$branchfile" &
+    fi
+    tail -f -n +1 "$branchfile"
+) | while read -a params; do
+    (
+	cd "$repo"
+	$top/svn-git-branch.sh --svntop "$svntop" "${params[@]}" < /dev/null
+    )
+done
diff --git a/contrib/svn-list-branches.sh b/contrib/svn-list-branches.sh
new file mode 100755
index 00000000000..1a3378f27b8
--- /dev/null
+++ b/contrib/svn-list-branches.sh
@@ -0,0 +1,108 @@
+#!/bin/bash
+
+set -euf -o pipefail
+
+svntop="svn+ssh://gcc.gnu.org/svn/gcc"
+verbose=0
+
+while test $# -gt 0; do
+    case "$1" in
+	--svntop) svntop="$2"; shift ;;
+	--verbose) verbose=$(($verbose+1)) ;;
+	--) shift; break ;;
+	*) break ;;
+    esac
+    shift
+done
+
+info ()
+{
+    if [ $verbose -ge 1 ]; then
+	echo "INFO: $@" >&2
+    fi
+}
+
+error ()
+{
+    echo "ERROR: $@" >&2
+    exit 1
+}
+
+if [ $verbose -ge 2 ]; then
+    set -x
+fi
+
+queue=()
+for i in "$@"; do
+    i=$(echo "$i" | sed -e "s#^/*##g" -e "s#/*\$##g")
+    queue=("$i")
+done
+
+tmp=$(mktemp)
+
+declare -A printed
+
+while [ "${#queue[@]}" -gt 0 ]; do
+    path="${queue[0]}"
+    queue=("${queue[@]:1}")
+
+    info "Processing $path"
+
+    svn ls "$svntop/$path" > $tmp
+    if grep -v -q "/\$" $tmp; then
+	copy_log=$(svn log -v --stop-on-copy "$svntop/$path" \
+		       | grep -A3 -e "------------------------------------------------------------------------" \
+		       | tail -n3 \
+		       | grep "^   A /.* (from /.*:[0-9]*)\$" \
+		       | tail -n 1)
+	if [ x"$copy_log" != x"" ]; then
+	    realpath="$(echo "$copy_log" | sed -e "s#^   A /\(.*\) (from /\(.*\):\([0-9]*\))\$#\1#")"
+	    parent="$(echo "$copy_log" | sed -e "s#^   A /\(.*\) (from /\(.*\):\([0-9]*\))\$#\2#")"
+	    parent_rev="$(echo "$copy_log" | sed -e "s#^   A /\(.*\) (from /\(.*\):\([0-9]*\))\$#\3#")"
+
+	    parent="$parent@$parent_rev"
+	    if [ x"${printed[$parent]+set}" != x"set" ]; then
+		queue=("$parent" "$path" "${queue[@]}")
+		info "Backtracking to $parent"
+		continue
+	    fi
+
+	    if [ x"$realpath" != x"${path%@*}" ]; then
+		rev=$(echo "$path" | cut -s -d@ -f 2)
+		if [ x"$rev" != x"" ]; then
+		    error "path $path is versioned and not a branch"
+		fi
+		path="$realpath"
+	    fi
+	fi
+
+	if [ x"${printed[$path]+set}" != x"set" ]; then
+	    printed[$path]=1
+
+	    printf "$path"
+	    while true; do
+		copy_log=$(svn log -v --stop-on-copy "$svntop/$path" \
+			       | grep -A3 -e "------------------------------------------------------------------------" \
+			       | tail -n3 \
+			       | grep "^   A /.* (from /.*:[0-9]*)\$" \
+			       | tail -n 1)
+		if [ x"$copy_log" = x"" ]; then
+		    break
+		fi
+
+		parent="$(echo "$copy_log" | sed -e "s#^   A /\(.*\) (from /\(.*\):\([0-9]*\))\$#\2#")"
+		parent_rev="$(echo "$copy_log" | sed -e "s#^   A /\(.*\) (from /\(.*\):\([0-9]*\))\$#\3#")"
+
+		path="$parent@$parent_rev"
+
+		printf " $path"
+	    done
+	    printf "\n"
+	fi
+    else
+	while read newpath; do
+	    newpath=$(echo "$path/$newpath" | sed -e "s#^/##g" -e "s#/\$##g")
+	    queue=("${queue[@]}" "$newpath")
+	done < $tmp
+    fi
+done
-- 
2.17.1

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Segher Boessenkool]

On Tue, May 14, 2019 at 07:11:18PM +0300, Maxim Kuvyrkov wrote:
> This patch adds scripts to contrib/ to migrate full history of GCC's
> subversion repository to git.  My hope is that these scripts will
> finally allow GCC project to migrate to Git.

Thank you for doing this.

> The result of the conversion is at
> https://github.com/maxim-kuvyrkov/gcc/branches/all .  Branches with
> "@rev" suffixes represent branch points.  The conversion is still
> running, so not all branches may appear right away.

What exactly is a branch point here?  Why is it useful to have tags
at branch points?  Why did you make branches instead of tags?


Only very lightly tested so far, but it looks promising.


Segher

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

> On May 15, 2019, at 12:20 AM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> 
> On Tue, May 14, 2019 at 07:11:18PM +0300, Maxim Kuvyrkov wrote:
>> This patch adds scripts to contrib/ to migrate full history of GCC's
>> subversion repository to git.  My hope is that these scripts will
>> finally allow GCC project to migrate to Git.
> 
> Thank you for doing this.
> 
>> The result of the conversion is at
>> https://github.com/maxim-kuvyrkov/gcc/branches/all .  Branches with
>> "@rev" suffixes represent branch points.  The conversion is still
>> running, so not all branches may appear right away.
> 
> What exactly is a branch point here?

Branch point corresponds to parent branch's revision at fork.

>  Why is it useful to have tags
> at branch points?

This is to speedup git-svn, which creates uses such entries internally.  We need them for conversion's internals; I deleted them from github copy to avoid clutter.

>  Why did you make branches instead of tags?

For simplicity purposes, it's internals after all.

> 
> Only very lightly tested so far, but it looks promising.
> 
> 
> Segher

I've fixed several cleanup bugs.  Updated patch attached.

--
Maxim Kuvyrkov
www.linaro.org



[-- Attachment #2: 0001-Contrib-SVN-Git-conversion-scripts.patch --]
[-- Type: application/octet-stream, Size: 8077 bytes --]

From 1ad9855e5dac2fcb2f6acb88798956a2c64512f5 Mon Sep 17 00:00:00 2001
From: Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>
Date: Tue, 14 May 2019 13:12:36 +0000
Subject: [PATCH] [Contrib] SVN -> Git conversion scripts

	* svn-git-repo.sh, svn-list-branches.sh, svn-git-branch.sh: New scripts.

Change-Id: I437d70c3bc431261bde5eec29e7207d4ebb0fe01
---
 contrib/svn-git-branch.sh    |  92 +++++++++++++++++++++++++++
 contrib/svn-git-repo.sh      |  58 +++++++++++++++++
 contrib/svn-list-branches.sh | 119 +++++++++++++++++++++++++++++++++++
 3 files changed, 269 insertions(+)
 create mode 100755 contrib/svn-git-branch.sh
 create mode 100755 contrib/svn-git-repo.sh
 create mode 100755 contrib/svn-list-branches.sh

diff --git a/contrib/svn-git-branch.sh b/contrib/svn-git-branch.sh
new file mode 100755
index 00000000000..9a746c4a8dd
--- /dev/null
+++ b/contrib/svn-git-branch.sh
@@ -0,0 +1,92 @@
+#!/bin/bash
+
+set -euf -o pipefail
+
+svntop="svn+ssh://gcc.gnu.org/svn/gcc"
+verbose=0
+
+while test $# -gt 0; do
+    case "$1" in
+	--svntop) svntop="$2"; shift ;;
+	--verbose) verbose=$(($verbose+1)) ;;
+	--) shift; break ;;
+	*) break ;;
+    esac
+    shift
+done
+
+info ()
+{
+    if [ $verbose -ge 1 ]; then
+	echo "INFO: $@" >&2
+    fi
+}
+
+if [ $verbose -ge 2 ]; then
+    set -x
+fi
+
+info "converting $@"
+
+spec="$1"
+shift 1
+
+branch=$(echo "$spec" | cut -d@ -f 1)
+rev=$(echo "$spec" | cut -s -d@ -f 2)
+
+for parent in "$@"; do
+    parent_branch=$(echo "$parent" | cut -d@ -f 1)
+    parent_rev=$(echo "$parent" | cut -s -d@ -f 2)
+
+    sha1=$(git rev-parse refs/remotes/svn/$parent)
+    mkdir -p $(dirname .git/refs/remotes/svn/$branch@$parent_rev)
+    echo $sha1 > .git/refs/remotes/svn/$branch@$parent_rev
+done
+
+sha1=""
+for i in svn/branches origin extra; do
+    if git rev-parse refs/remotes/$i/${branch#branches/} >/dev/null 2>&1; then
+	sha1=$(git rev-parse refs/remotes/$i/${branch#branches/})
+    fi
+done
+
+if [ x"$sha1" != x"" ]; then
+    if ! git rev-parse refs/remotes/cache/$branch >/dev/null 2>&1 \
+	   || [ x"$rev" != x"" ]; then
+	mkdir -p $(dirname .git/refs/remotes/cache/$branch)
+	echo $sha1 > .git/refs/remotes/cache/$branch
+
+	cat >> .git/config <<EOF
+
+[svn-remote "cache-$branch"]
+	url = svn+ssh://gcc.gnu.org/svn/gcc
+	fetch = $branch:refs/remotes/cache/$branch
+EOF
+	git svn fetch --log-window-size=10000 "cache-$branch"
+
+	if [ x"$rev" != x"" ]; then
+	    sha1=$(git svn find-rev --before r$rev refs/remotes/cache/$branch)
+	else
+	    sha1=$(git rev-parse refs/remotes/cache/$branch)
+	fi
+
+	head -n -4 .git/config > .git/newconfig
+	mv .git/newconfig .git/config
+    else
+	sha1=$(git rev-parse refs/remotes/cache/$branch)
+    fi
+
+    mkdir -p $(dirname .git/refs/remotes/svn/$spec)
+    echo $sha1 > .git/refs/remotes/svn/$spec
+fi
+
+cat >> .git/config <<EOF
+
+[svn-remote "$spec"]
+	url = svn+ssh://gcc.gnu.org/svn/gcc
+	fetch = $branch:refs/remotes/svn/$spec
+EOF
+
+git svn fetch ${rev:+-r BASE:$rev} --log-window-size=10000 "$spec"
+head -n -4 .git/config > .git/newconfig
+mv .git/newconfig .git/config
diff --git a/contrib/svn-git-repo.sh b/contrib/svn-git-repo.sh
new file mode 100755
index 00000000000..1cbf712467f
--- /dev/null
+++ b/contrib/svn-git-repo.sh
@@ -0,0 +1,58 @@
+#!/bin/bash
+
+set -euf -o pipefail
+
+branchfile=""
+giturl=https://gcc.gnu.org/git/gcc.git
+reference=""
+repo=""
+svnpaths=()
+svntop=svn+ssh://gcc.gnu.org/svn/gcc
+
+while test $# -gt 0; do
+    case "$1" in
+	--branchfile) branchfile="$2"; shift ;;
+	--giturl) giturl="$2"; shift ;;
+	--reference) reference="$2"; shift ;;
+	--repo) repo="$2"; shift ;;
+	--svnpath) svnpaths+=("$2"); shift ;;
+	--svntop) svntop="$2"; shift ;;
+	--verbose) set -x ;;
+	*) echo "ERROR: wrong argument: $1"; exit 1 ;;
+    esac
+    shift
+done
+
+top=$(cd $(dirname "$0"); pwd)
+
+if [ x"$repo" = x"" ]; then
+    echo "ERROR: no --repo /path/to/repo"
+    exit 1
+elif [ -d "$repo" ]; then
+    echo "ERROR: directory $repo exists"
+    echo "       rename it to $repo.bak if it is a good starting point"
+    exit 1
+fi
+
+if [ -d "$repo.bak" ]; then
+    rsync -a --del "$repo.bak/" "$repo/"
+else
+    git clone ${reference:+--reference "$reference"} "$giturl" "$repo"
+    git -C "$repo" config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/extra/*'
+    git -C "$repo" remote update -p
+    rsync -a --del "$repo/" "$repo.bak/"
+fi
+
+(
+    if [ x"$branchfile" = x"" ]; then
+	$top/svn-list-branches.sh --svntop "$svntop" "${svnpaths[@]}" \
+	    | tee $(mktemp)
+    else
+	cat "$branchfile"
+    fi
+) | while read -a params; do
+    (
+	cd "$repo"
+	$top/svn-git-branch.sh --svntop "$svntop" "${params[@]}" < /dev/null
+    )
+done
diff --git a/contrib/svn-list-branches.sh b/contrib/svn-list-branches.sh
new file mode 100755
index 00000000000..699c6458e3b
--- /dev/null
+++ b/contrib/svn-list-branches.sh
@@ -0,0 +1,119 @@
+#!/bin/bash
+
+set -euf -o pipefail
+
+svntop="svn+ssh://gcc.gnu.org/svn/gcc"
+verbose=0
+
+while test $# -gt 0; do
+    case "$1" in
+	--svntop) svntop="$2"; shift ;;
+	--verbose) verbose=$(($verbose+1)) ;;
+	--) shift; break ;;
+	*) break ;;
+    esac
+    shift
+done
+
+info ()
+{
+    if [ $verbose -ge 1 ]; then
+	echo "INFO: $@" >&2
+    fi
+}
+
+error ()
+{
+    echo "ERROR: $@" >&2
+    exit 1
+}
+
+if [ $verbose -ge 2 ]; then
+    set -x
+fi
+
+queue=()
+for i in "$@"; do
+    i=$(echo "$i" | sed -e "s#^/*##g" -e "s#/*\$##g")
+    queue+=("$i")
+done
+
+if [ "${#queue[@]}" = 0 ]; then
+    queue=("")
+fi
+
+tmp=$(mktemp)
+
+declare -A printed
+
+while [ "${#queue[@]}" -gt 0 ]; do
+    path="${queue[0]}"
+    queue=("${queue[@]:1}")
+
+    info "Processing $path"
+
+    if ! echo "$path" | grep -q ".*@[0-9]\+\$"; then
+	svn ls "$svntop/$path" > $tmp
+    else
+	echo "foo/bar" > $tmp
+    fi
+
+    if grep -v -q "/\$" $tmp; then
+	copy_log=$(set +o pipefail;
+		   svn log -v --stop-on-copy "$svntop/$path" \
+		       | grep -A3 -e "------------------------------------------------------------------------" \
+		       | tail -n3 \
+		       | grep "^   A /.* (from /.*:[0-9]*)\$" \
+		       | tail -n 1)
+	if [ x"$copy_log" != x"" ]; then
+	    realpath="$(echo "$copy_log" | sed -e "s#^   A /\(.*\) (from /\(.*\):\([0-9]*\))\$#\1#")"
+	    parent="$(echo "$copy_log" | sed -e "s#^   A /\(.*\) (from /\(.*\):\([0-9]*\))\$#\2#")"
+	    parent_rev="$(echo "$copy_log" | sed -e "s#^   A /\(.*\) (from /\(.*\):\([0-9]*\))\$#\3#")"
+
+	    parent="$parent@$parent_rev"
+	    if [ x"${printed[$parent]+set}" != x"set" ]; then
+		queue=("$parent" "$path" "${queue[@]}")
+		info "Backtracking to $parent"
+		continue
+	    fi
+
+	    if [ x"$realpath" != x"${path%@*}" ]; then
+		rev=$(echo "$path" | cut -s -d@ -f 2)
+		if [ x"$rev" != x"" ]; then
+		    error "path $path is versioned and not a branch"
+		fi
+		path="$realpath"
+	    fi
+	fi
+
+	if [ x"${printed[$path]+set}" != x"set" ]; then
+	    printed[$path]=1
+
+	    printf "$path"
+	    while true; do
+		copy_log=$(set +o pipefail;
+			   svn log -v --stop-on-copy "$svntop/$path" \
+			       | grep -A3 -e "------------------------------------------------------------------------" \
+			       | tail -n3 \
+			       | grep "^   A /.* (from /.*:[0-9]*)\$" \
+			       | tail -n 1)
+		if [ x"$copy_log" = x"" ]; then
+		    break
+		fi
+
+		parent="$(echo "$copy_log" | sed -e "s#^   A /\(.*\) (from /\(.*\):\([0-9]*\))\$#\2#")"
+		parent_rev="$(echo "$copy_log" | sed -e "s#^   A /\(.*\) (from /\(.*\):\([0-9]*\))\$#\3#")"
+
+		path="$parent@$parent_rev"
+
+		printf " $path"
+	    done
+	    printf "\n"
+	fi
+    else
+	while read newpath; do
+	    newpath=$(echo "$path/$newpath" | sed -e "s#^/##g" -e "s#/\$##g")
+	    queue=("${queue[@]}" "$newpath")
+	done < $tmp
+    fi
+done
-- 
2.17.1

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Segher Boessenkool]

On Wed, May 15, 2019 at 11:34:34AM +0300, Maxim Kuvyrkov wrote:
> > On May 15, 2019, at 12:20 AM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> > On Tue, May 14, 2019 at 07:11:18PM +0300, Maxim Kuvyrkov wrote:
> >> This patch adds scripts to contrib/ to migrate full history of GCC's
> >> subversion repository to git.  My hope is that these scripts will
> >> finally allow GCC project to migrate to Git.
> > 
> > Thank you for doing this.
> > 
> >> The result of the conversion is at
> >> https://github.com/maxim-kuvyrkov/gcc/branches/all .  Branches with
> >> "@rev" suffixes represent branch points.  The conversion is still
> >> running, so not all branches may appear right away.
> > 
> > What exactly is a branch point here?
> 
> Branch point corresponds to parent branch's revision at fork.
> 
> >  Why is it useful to have tags
> > at branch points?
> 
> This is to speedup git-svn, which creates uses such entries internally.  We need them for conversion's internals; I deleted them from github copy to avoid clutter.

Ah!  Great.  Looks better now :-)

Has it finished conversion yet?  I don't see all branches.


Segher

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On May 15, 2019, at 9:47 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> 
> On Wed, May 15, 2019 at 11:34:34AM +0300, Maxim Kuvyrkov wrote:
>>> On May 15, 2019, at 12:20 AM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
>>> On Tue, May 14, 2019 at 07:11:18PM +0300, Maxim Kuvyrkov wrote:
>>>> This patch adds scripts to contrib/ to migrate full history of GCC's
>>>> subversion repository to git.  My hope is that these scripts will
>>>> finally allow GCC project to migrate to Git.
>>> 
>>> Thank you for doing this.
>>> 
>>>> The result of the conversion is at
>>>> https://github.com/maxim-kuvyrkov/gcc/branches/all .  Branches with
>>>> "@rev" suffixes represent branch points.  The conversion is still
>>>> running, so not all branches may appear right away.
>>> 
>>> What exactly is a branch point here?
>> 
>> Branch point corresponds to parent branch's revision at fork.
>> 
>>> Why is it useful to have tags
>>> at branch points?
>> 
>> This is to speedup git-svn, which creates uses such entries internally.  We need them for conversion's internals; I deleted them from github copy to avoid clutter.
> 
> Ah!  Great.  Looks better now :-)
> 
> Has it finished conversion yet?  I don't see all branches.

Still running.  I had to restart it a few times to fix bugs in the corner cases and to speed it up.  Luckily, the scripts seem to be able to pick up where they left off, so I restarts are relatively cheap.

For those interested in fixes and changes between scripts versions, I'm uploading updated patches to https://review.linaro.org/#/c/toolchain/gcc/+/31416/ .

--
Maxim Kuvyrkov
www.linaro.org

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Richard Biener]

On Tue, May 14, 2019 at 6:11 PM Maxim Kuvyrkov
<maxim.kuvyrkov@linaro.org> wrote:
>
> This patch adds scripts to contrib/ to migrate full history of GCC's subversion repository to git.  My hope is that these scripts will finally allow GCC project to migrate to Git.
>
> The result of the conversion is at https://github.com/maxim-kuvyrkov/gcc/branches/all .  Branches with "@rev" suffixes represent branch points.  The conversion is still running, so not all branches may appear right away.
>
> The scripts are not specific to GCC repo and are usable for other projects.  In particular, they should be able to convert downstream GCC svn repos.
>
> The scripts convert svn history branch by branch.  They rely on git-svn on convert individual branches.  Git-svn is a good tool for converting individual branches.  It is, however, either very slow at converting the entire GCC repo, or goes into infinite loop.
>
> There are 3 scripts:
>
> - svn-git-repo.sh: top level script to convert entire repo or a part of it (e.g., branches/),
> - svn-list-branches.sh: helper script to output branches and their parents in bottom-up order,
> - svn-git-branch.sh: helper script to convert a single branch.
>
> Whenever possible, svn-git-branch.sh uses existing git branches as caches.
>
> What are your questions and comments?

Any comments on how it deals with "errors" like removing trunk which
happened a few times?
(not sure what other "errors" Eric refers to reposurgeon "deals" with...)

I suppose it converts only history of not deleted branches?

For the official converted repo do we really want all (old)
development branches to be in the
main git repo?  I suppose we could create a readonly git from the
state of the whole repository
at the point of conversion (and also keep the SVN in readonly mode),
just to make migration
of content we want easy in the future?

> The attached is cleaned up version, which hasn't been fully tested yet; typos and other silly mistakes are likely.  OK to commit after testing?

Thanks for taking up this ball!

Richard.

> --
> Maxim Kuvyrkov
> www.linaro.org
>
>

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On May 15, 2019, at 2:19 PM, Richard Biener <richard.guenther@gmail.com> wrote:
> 
> On Tue, May 14, 2019 at 6:11 PM Maxim Kuvyrkov
> <maxim.kuvyrkov@linaro.org> wrote:
>> 
>> This patch adds scripts to contrib/ to migrate full history of GCC's subversion repository to git.  My hope is that these scripts will finally allow GCC project to migrate to Git.
>> 
>> The result of the conversion is at https://github.com/maxim-kuvyrkov/gcc/branches/all . Branches with "@rev" suffixes represent branch points.  The conversion is still running, so not all branches may appear right away.
>> 
>> The scripts are not specific to GCC repo and are usable for other projects.  In particular, they should be able to convert downstream GCC svn repos.
>> 
>> The scripts convert svn history branch by branch.  They rely on git-svn on convert individual branches.  Git-svn is a good tool for converting individual branches.  It is, however, either very slow at converting the entire GCC repo, or goes into infinite loop.
>> 
>> There are 3 scripts:
>> 
>> - svn-git-repo.sh: top level script to convert entire repo or a part of it (e.g., branches/),
>> - svn-list-branches.sh: helper script to output branches and their parents in bottom-up order,
>> - svn-git-branch.sh: helper script to convert a single branch.
>> 
>> Whenever possible, svn-git-branch.sh uses existing git branches as caches.
>> 
>> What are your questions and comments?
> 
> Any comments on how it deals with "errors" like removing trunk which
> happened a few times?
> (not sure what other "errors" Eric refers to reposurgeon "deals" with...)

Stock git-svn can deal with deleted parents; e.g., for the first deletion of trunk, git-svn treats trunk@180802 as a /generic/ parent path for trunk, and happily follows its history.

> 
> I suppose it converts only history of not deleted branches?

The scripts can convert history of deleted and moved branches.  E.g., branches/gcc-3_2-rhl8-branch was moved (which is copy and delete for svn) to branches/redhat/gcc-3_2-rhl8-branch around revision 95470, so one would need to point the scripts to branches/gcc-3_2-rhl8-branch@95470 to convert its history.  Something like:

./svn-git-repo.sh --repo $HOME/gcc-branches --svnpath branches/gcc-3_2-rhl8-branch@95470

> 
> For the official converted repo do we really want all (old)
> development branches to be in the
> main git repo?  I suppose we could create a readonly git from the
> state of the whole repository
> at the point of conversion (and also keep the SVN in readonly mode),
> just to make migration
> of content we want easy in the future?

Having a single full repo is simpler than having the main repo and the full one with all the history.  So, unless full repo is twice the size of the main one, let's keep all the branches.

We can also give a shout to representatives of RedHat, Google, and others to voluntarily remove their old maintenance branches from the repo, and, possibly, stash them somewhere on github.

> 
>> The attached is cleaned up version, which hasn't been fully tested yet; typos and other silly mistakes are likely.  OK to commit after testing?
> 
> Thanks for taking up this ball!

--
Maxim Kuvyrkov
www.linaro.org

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Eric Gallager]

On 5/15/19, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
>> On May 15, 2019, at 2:19 PM, Richard Biener <richard.guenther@gmail.com>
>> wrote:
>>
>> On Tue, May 14, 2019 at 6:11 PM Maxim Kuvyrkov
>> <maxim.kuvyrkov@linaro.org> wrote:
>>>
>>> This patch adds scripts to contrib/ to migrate full history of GCC's
>>> subversion repository to git.  My hope is that these scripts will finally
>>> allow GCC project to migrate to Git.
>>>
>>> The result of the conversion is at
>>> https://github.com/maxim-kuvyrkov/gcc/branches/all . Branches with "@rev"
>>> suffixes represent branch points.  The conversion is still running, so
>>> not all branches may appear right away.
>>>
>>> The scripts are not specific to GCC repo and are usable for other
>>> projects.  In particular, they should be able to convert downstream GCC
>>> svn repos.
>>>
>>> The scripts convert svn history branch by branch.  They rely on git-svn
>>> on convert individual branches.  Git-svn is a good tool for converting
>>> individual branches.  It is, however, either very slow at converting the
>>> entire GCC repo, or goes into infinite loop.
>>>
>>> There are 3 scripts:
>>>
>>> - svn-git-repo.sh: top level script to convert entire repo or a part of
>>> it (e.g., branches/),
>>> - svn-list-branches.sh: helper script to output branches and their
>>> parents in bottom-up order,
>>> - svn-git-branch.sh: helper script to convert a single branch.
>>>
>>> Whenever possible, svn-git-branch.sh uses existing git branches as
>>> caches.
>>>
>>> What are your questions and comments?
>>
>> Any comments on how it deals with "errors" like removing trunk which
>> happened a few times?
>> (not sure what other "errors" Eric refers to reposurgeon "deals" with...)
>
> Stock git-svn can deal with deleted parents; e.g., for the first deletion of
> trunk, git-svn treats trunk@180802 as a /generic/ parent path for trunk, and
> happily follows its history.
>
>>
>> I suppose it converts only history of not deleted branches?
>
> The scripts can convert history of deleted and moved branches.  E.g.,
> branches/gcc-3_2-rhl8-branch was moved (which is copy and delete for svn) to
> branches/redhat/gcc-3_2-rhl8-branch around revision 95470, so one would need
> to point the scripts to branches/gcc-3_2-rhl8-branch@95470 to convert its
> history.  Something like:
>
> ./svn-git-repo.sh --repo $HOME/gcc-branches --svnpath
> branches/gcc-3_2-rhl8-branch@95470
>
>>
>> For the official converted repo do we really want all (old)
>> development branches to be in the
>> main git repo?  I suppose we could create a readonly git from the
>> state of the whole repository
>> at the point of conversion (and also keep the SVN in readonly mode),
>> just to make migration
>> of content we want easy in the future?
>
> Having a single full repo is simpler than having the main repo and the full
> one with all the history.  So, unless full repo is twice the size of the
> main one, let's keep all the branches.
>
> We can also give a shout to representatives of RedHat, Google, and others to
> voluntarily remove their old maintenance branches from the repo, and,
> possibly, stash them somewhere on github.
>
>>
>>> The attached is cleaned up version, which hasn't been fully tested yet;
>>> typos and other silly mistakes are likely.  OK to commit after testing?
>>
>> Thanks for taking up this ball!
>
> --
> Maxim Kuvyrkov
> www.linaro.org
>

Wasn't Eric S. Raymond working on his own conversion of the GCC repo
from SVN to Git? Whatever happened to his?

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Paul Koning]

> On May 15, 2019, at 2:42 PM, Eric Gallager <egall@gwmail.gwu.edu> wrote:
> 
>> ...
> 
> Wasn't Eric S. Raymond working on his own conversion of the GCC repo
> from SVN to Git? Whatever happened to his?

Yes, and from what I recall he found that doing it fully correctly is an extremely hard task.  It might be a good idea to ask him to comment.

	paul

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On May 16, 2019, at 3:33 AM, Paul Koning <paulkoning@comcast.net> wrote:
> 
> 
> 
>> On May 15, 2019, at 2:42 PM, Eric Gallager <egall@gwmail.gwu.edu> wrote:
>> 
>>> ...
>> 
>> Wasn't Eric S. Raymond working on his own conversion of the GCC repo
>> from SVN to Git? Whatever happened to his?
> 
> Yes, and from what I recall he found that doing it fully correctly is an extremely hard task.  It might be a good idea to ask him to comment.

That's a good suggestion; thanks, Paul.

Hi Eric,

The svn->git conversion scripts I'm testing work on individual svn branches, and I would appreciate a list of svn branches in GCC's repo that caused problems.  It would be best to double-check conversion of these branches for any artifacts.

Regards,

--
Maxim Kuvyrkov
www.linaro.org

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Jeff Law]

On 5/15/19 5:19 AM, Richard Biener wrote:
> 
> For the official converted repo do we really want all (old)
> development branches to be in the
> main git repo?  I suppose we could create a readonly git from the
> state of the whole repository
> at the point of conversion (and also keep the SVN in readonly mode),
> just to make migration
> of content we want easy in the future?
I've always assumed we'd keep the old SVN tree read-only for historical
purposes.  I strongly suspect that, ignoring release branches, that
non-active branches just aren't terribly interesting.


Jeff

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On May 16, 2019, at 7:22 PM, Jeff Law <law@redhat.com> wrote:
> 
> On 5/15/19 5:19 AM, Richard Biener wrote:
>> 
>> For the official converted repo do we really want all (old)
>> development branches to be in the
>> main git repo?  I suppose we could create a readonly git from the
>> state of the whole repository
>> at the point of conversion (and also keep the SVN in readonly mode),
>> just to make migration
>> of content we want easy in the future?
> I've always assumed we'd keep the old SVN tree read-only for historical
> purposes.  I strongly suspect that, ignoring release branches, that
> non-active branches just aren't terribly interesting.

Let's avoid mixing the two discussions: (1) converting svn repo to git (and getting community consensus to switch to git) and (2) deciding on which branches to keep in the new repo.

With git, we can always split away unneeded history by removing unnecessary branches and tags and re-packing the repo.  We can equally easily bring that history back if we change our minds.

--
Maxim Kuvyrkov
www.linaro.org

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Ramana Radhakrishnan]

On Thu, May 16, 2019 at 5:41 PM Maxim Kuvyrkov
<maxim.kuvyrkov@linaro.org> wrote:
>
> > On May 16, 2019, at 7:22 PM, Jeff Law <law@redhat.com> wrote:
> >
> > On 5/15/19 5:19 AM, Richard Biener wrote:
> >>
> >> For the official converted repo do we really want all (old)
> >> development branches to be in the
> >> main git repo?  I suppose we could create a readonly git from the
> >> state of the whole repository
> >> at the point of conversion (and also keep the SVN in readonly mode),
> >> just to make migration
> >> of content we want easy in the future?
> > I've always assumed we'd keep the old SVN tree read-only for historical
> > purposes.  I strongly suspect that, ignoring release branches, that
> > non-active branches just aren't terribly interesting.
>
> Let's avoid mixing the two discussions: (1) converting svn repo to git (and getting community consensus to switch to git) and (2) deciding on which branches to keep in the new repo.
>

I'm hoping that there is still community consensus to switch to git.

Personally speaking, a +1 to switch to git.

regards
Ramana

> With git, we can always split away unneeded history by removing unnecessary branches and tags and re-packing the repo.  We can equally easily bring that history back if we change our minds.
>
> --
> Maxim Kuvyrkov
> www.linaro.org
>

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Jeff Law]

On 5/16/19 12:36 PM, Ramana Radhakrishnan wrote:
> On Thu, May 16, 2019 at 5:41 PM Maxim Kuvyrkov
> <maxim.kuvyrkov@linaro.org> wrote:
>>
>>> On May 16, 2019, at 7:22 PM, Jeff Law <law@redhat.com> wrote:
>>>
>>> On 5/15/19 5:19 AM, Richard Biener wrote:
>>>>
>>>> For the official converted repo do we really want all (old)
>>>> development branches to be in the
>>>> main git repo?  I suppose we could create a readonly git from the
>>>> state of the whole repository
>>>> at the point of conversion (and also keep the SVN in readonly mode),
>>>> just to make migration
>>>> of content we want easy in the future?
>>> I've always assumed we'd keep the old SVN tree read-only for historical
>>> purposes.  I strongly suspect that, ignoring release branches, that
>>> non-active branches just aren't terribly interesting.
>>
>> Let's avoid mixing the two discussions: (1) converting svn repo to git (and getting community consensus to switch to git) and (2) deciding on which branches to keep in the new repo.
>>
> 
> I'm hoping that there is still community consensus to switch to git.
> 
> Personally speaking, a +1 to switch to git.
Absolutely +1 for converting as well.

jeff

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Jonathan Wakely]

On 16/05/19 13:07 -0600, Jeff Law wrote:
>On 5/16/19 12:36 PM, Ramana Radhakrishnan wrote:
>> On Thu, May 16, 2019 at 5:41 PM Maxim Kuvyrkov
>> <maxim.kuvyrkov@linaro.org> wrote:
>>>
>>>> On May 16, 2019, at 7:22 PM, Jeff Law <law@redhat.com> wrote:
>>>>
>>>> On 5/15/19 5:19 AM, Richard Biener wrote:
>>>>>
>>>>> For the official converted repo do we really want all (old)
>>>>> development branches to be in the
>>>>> main git repo?  I suppose we could create a readonly git from the
>>>>> state of the whole repository
>>>>> at the point of conversion (and also keep the SVN in readonly mode),
>>>>> just to make migration
>>>>> of content we want easy in the future?
>>>> I've always assumed we'd keep the old SVN tree read-only for historical
>>>> purposes.  I strongly suspect that, ignoring release branches, that
>>>> non-active branches just aren't terribly interesting.
>>>
>>> Let's avoid mixing the two discussions: (1) converting svn repo to git (and getting community consensus to switch to git) and (2) deciding on which branches to keep in the new repo.
>>>
>>
>> I'm hoping that there is still community consensus to switch to git.
>>
>> Personally speaking, a +1 to switch to git.
>Absolutely +1 for converting as well.

Yes please!

Thanks for working on this, Maxim.

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Martin Liška]

On 5/17/19 12:04 AM, Jonathan Wakely wrote:
> On 16/05/19 13:07 -0600, Jeff Law wrote:
>> On 5/16/19 12:36 PM, Ramana Radhakrishnan wrote:
>>> On Thu, May 16, 2019 at 5:41 PM Maxim Kuvyrkov
>>> <maxim.kuvyrkov@linaro.org> wrote:
>>>>
>>>>> On May 16, 2019, at 7:22 PM, Jeff Law <law@redhat.com> wrote:
>>>>>
>>>>> On 5/15/19 5:19 AM, Richard Biener wrote:
>>>>>>
>>>>>> For the official converted repo do we really want all (old)
>>>>>> development branches to be in the
>>>>>> main git repo?  I suppose we could create a readonly git from the
>>>>>> state of the whole repository
>>>>>> at the point of conversion (and also keep the SVN in readonly mode),
>>>>>> just to make migration
>>>>>> of content we want easy in the future?
>>>>> I've always assumed we'd keep the old SVN tree read-only for historical
>>>>> purposes.  I strongly suspect that, ignoring release branches, that
>>>>> non-active branches just aren't terribly interesting.
>>>>
>>>> Let's avoid mixing the two discussions: (1) converting svn repo to git (and getting community consensus to switch to git) and (2) deciding on which branches to keep in the new repo.
>>>>
>>>
>>> I'm hoping that there is still community consensus to switch to git.
>>>
>>> Personally speaking, a +1 to switch to git.
>> Absolutely +1 for converting as well.
> 
> Yes please!
> 
> Thanks for working on this, Maxim.
> 
> 

I fully support that and thank you Maxim for working on that!

Martin

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Joseph Myers]

On Thu, 16 May 2019, Maxim Kuvyrkov wrote:

> Let's avoid mixing the two discussions: (1) converting svn repo to git 
> (and getting community consensus to switch to git) and (2) deciding on 
> which branches to keep in the new repo.
> 
> With git, we can always split away unneeded history by removing 
> unnecessary branches and tags and re-packing the repo.  We can equally 
> easily bring that history back if we change our minds.

A prerequisite of a move to git is to have policies on branch deletion / 
force-pushes, and hook implementations that ensure those policies are 
followed (as well as implementing what's agreed on commit messages, 
Bugzilla updates, etc.).  There has of course been a lot of past 
discussion of those that someone will need to find, read and describe the 
issues and conclusions from.  I think there was a view that branch 
deletion and force-pushes should be limited to a particular namespace for 
user branches.

(I support a move to git, but not one using git-svn, and only one that 
properly takes into account the large amount of work previously done on 
author maps, understanding the repository peculiarities and how to 
correctly identify exactly which directories are branches or tags, fixing 
cases where there are both a branch and tag of the same name, identifying 
which tags to remove and which to keep, etc.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Richard Sandiford]

Joseph Myers <joseph@codesourcery.com> writes:
> On Thu, 16 May 2019, Maxim Kuvyrkov wrote:
>
>> Let's avoid mixing the two discussions: (1) converting svn repo to git 
>> (and getting community consensus to switch to git) and (2) deciding on 
>> which branches to keep in the new repo.
>> 
>> With git, we can always split away unneeded history by removing 
>> unnecessary branches and tags and re-packing the repo.  We can equally 
>> easily bring that history back if we change our minds.
>
> A prerequisite of a move to git is to have policies on branch deletion / 
> force-pushes, and hook implementations that ensure those policies are 
> followed (as well as implementing what's agreed on commit messages, 
> Bugzilla updates, etc.).  There has of course been a lot of past 
> discussion of those that someone will need to find, read and describe the 
> issues and conclusions from.  I think there was a view that branch 
> deletion and force-pushes should be limited to a particular namespace for 
> user branches.

We're not starting from scratch on that though.  The public git
(semi-)mirror has been going for a long time, so IMO we should just
inherit the policies for that.  (Like you say, forced pushed are
restricted to the user namespace.)  Policies can evoluve over time :-)

Agreeing on a format for commit messages would be good, but IMO it's
a separate improvement to the repo discussion.  We don't have an agreed
format for SVN commit messages either, and although it's not ideal,
it doesn't make SVN unworkable.  The same would be true for git.
Whatever policy we come up with can't apply retrospectively anyway,
so the full git history is always going to have a mixture of styles.

And I think that's the major downside of putting so many barriers
in the way of the conversion.  Switching to git without new commit
message guidelines might not be perfect, but if we'd done it two years
ago anyway, people would have been committing (mostly) git-friendly
commits since then, even if the messages weren't very consistent.
Whereas at the moment, many commit messages are neither git-friendly
nor consistent.  And that's going to continue to be the case until
we switch.

So although the intention of these requirements seems to be to make the
final git history as good as it can be, I think in practice it's having
the opposite effect.

> (I support a move to git, but not one using git-svn, and only one that 
> properly takes into account the large amount of work previously done on 
> author maps, understanding the repository peculiarities and how to 
> correctly identify exactly which directories are branches or tags, fixing 
> cases where there are both a branch and tag of the same name, identifying 
> which tags to remove and which to keep, etc.)

But the discussion upthread seemed to be that having the very old stuff
in git wasn't necessarily that important anyway.

FWIW, I've been using the "official" git-svn based mirror for at least
the last five years, only using SVN to actually commit.  And I've never
needed any of the above during that time.

E.g. having proper author names seems like a nice-to-have rather than
a requirement.  A lot of the effort spent on compiling that list seemed
to be getting names and email addresses for people who haven't contributed
to gcc for a long time (in some cases 20 years or more).  It's interesting
historical data, but in almost all cases, the email addresses used are
going to be defunct anyway.

It would be a really neat project to create a GCC git repo that goes
far back in time and gives the closest illusion possible that git had
been used all that time.  And personally I'd be very interested in
seeing that.  But its main use would be as a historical artefact,
to show how a long-running software project evolved over time.

I think the focus for the development git repo should be on what's
needed for day-to-day work, and like I say, the git-svn mirror we
have now is in practice a good enough conversion for that.  If we can
do better then great.  But I think we're in serious danger of making the
best the enemy of the good here.

The big advantage of Maxim's approach is that it's a public script in
our own repo that anyone can contribute to.  So if there are specific
tweaks people want to make, there's now the opportunity to do that.

So FWIW, my vote would be for having a window to allow people to tweak
the script if they want to, then make the switch.

Thanks,
Richard

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Segher Boessenkool]

On Fri, May 17, 2019 at 09:18:53AM +0100, Richard Sandiford wrote:
> Joseph Myers <joseph@codesourcery.com> writes:
> > On Thu, 16 May 2019, Maxim Kuvyrkov wrote:
> >> With git, we can always split away unneeded history by removing 
> >> unnecessary branches and tags and re-packing the repo.  We can equally 
> >> easily bring that history back if we change our minds.

Only if we have stored it somewhere!  But we all agree we will never
delete any (non-user) branches I think.

> > (I support a move to git, but not one using git-svn, and only one that 
> > properly takes into account the large amount of work previously done on 
> > author maps, understanding the repository peculiarities and how to 

I am very much **against** most of that author map stuff.  It is falsifying
history.  Replacing the sourceware account name of people by one of their
current email addresses is just foolish anyway.

In many cases anyone can trivially glance the correct info from the
changelogs.  In some other cases it is hard or impossible to find the
correct info.

The information we have now in SVN is what we have there now.  We should
convert *that* information to Git, nothing more, nothing less.  And that
is very much possible to do, not a gargantuan task.

> > correctly identify exactly which directories are branches or tags, fixing 
> > cases where there are both a branch and tag of the same name, identifying 
> > which tags to remove and which to keep, etc.)

Yes -- one of the problems I have with the current git-svn mirror is that
it doesn't have any of the SVN branches under ibm/ as separate Git branches.
It looks like Maxim's scripts will handle this; the conversion hasn't
reached those branches yet though.  Soon :-)

> FWIW, I've been using the "official" git-svn based mirror for at least
> the last five years, only using SVN to actually commit.  And I've never
> needed any of the above during that time.

I do look through all history pretty often.  The current mirror is good
enough for most of that, and there is no way to get the rest back AFAIK.

> It would be a really neat project to create a GCC git repo that goes
> far back in time and gives the closest illusion possible that git had
> been used all that time.  And personally I'd be very interested in
> seeing that.  But its main use would be as a historical artefact,
> to show how a long-running software project evolved over time.

Agreed.

> I think the focus for the development git repo should be on what's
> needed for day-to-day work, and like I say, the git-svn mirror we
> have now is in practice a good enough conversion for that.  If we can
> do better then great.  But I think we're in serious danger of making the
> best the enemy of the good here.

Yes.  There are a few things that should be fixed though, like that branches
vs. tags thing, and the subdir branches problem.

> The big advantage of Maxim's approach is that it's a public script in
> our own repo that anyone can contribute to.  So if there are specific
> tweaks people want to make, there's now the opportunity to do that.
> 
> So FWIW, my vote would be for having a window to allow people to tweak
> the script if they want to, then make the switch.

I agree.


Segher

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Steve Ellcey]

I hope this isn't too much of a thread drift but I was wondering if,
after the Git conversion, will the GCC repo look like a 'normal' GIT
repo with the main line sources on the master branch?

I.e. right now instead of a simple clone, the GCC Wiki says to use a
sequence of git init/config/fetch/checkout commands.  After the
conversion will we be able to just use 'git clone'?  And will the
default master branch be the usable GCC top-of-tree sources (vs the
trunk branch) that we can do checkins to?

Steve Ellcey
sellcey@marvell.com

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Jason Merrill]

On Fri, May 17, 2019 at 3:51 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
> Yes -- one of the problems I have with the current git-svn mirror is that
> it doesn't have any of the SVN branches under ibm/ as separate Git branches.
> It looks like Maxim's scripts will handle this; the conversion hasn't
> reached those branches yet though.  Soon :-)

I talk about how to rewrite subdirectory branches without doing the
slow git-svn checkout in

https://gcc.gnu.org/wiki/GitMirror#Subdirectory_branches

Jason

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Joseph Myers]

On Fri, 17 May 2019, Richard Sandiford wrote:

> We're not starting from scratch on that though.  The public git
> (semi-)mirror has been going for a long time, so IMO we should just
> inherit the policies for that.  (Like you say, forced pushed are
> restricted to the user namespace.)  Policies can evoluve over time :-)

It doesn't send anything to gcc-cvs or to Bugzilla, so we need to define 
what goes there, for example, and implement it (presumably as far as 
possible by configuring one of the sets of git hooks already in use on 
sourceware, e.g. the AdaCore ones used for binutils/gdb and glibc, rather 
than writing our own from scratch).  (When referring to commit messages I 
was thinking about the messages on gcc-cvs rather than the messages 
written by committers; I agree that the format of the latter is 
independent of a move to git, and have been using git-style messages for 
commits to GCC for some time.)

> But the discussion upthread seemed to be that having the very old stuff
> in git wasn't necessarily that important anyway.

I think git should have all the branches that haven't been deleted in SVN, 
minus any where there is a specific decision to remove in the conversion 
(messed up history, branch was an artefact of conversion from CVS rather 
than a real branch, etc.).  If a branch or tag has been deleted in SVN it 
should not be brought across to the git repository (SVN will remain 
readonly, just as the old CVS repository remains available readonly).

> FWIW, I've been using the "official" git-svn based mirror for at least
> the last five years, only using SVN to actually commit.  And I've never
> needed any of the above during that time.

That the git-svn mirror is useful for many purposes for which people want 
to use git also provides a clear argument against needing to do the final 
conversion in a hurry; people can use it when convenient while we take the 
time to get the conversion right (in particular, seeing what the Go 
conversion of reposurgeon comes up with), and then rebase their git 
branches on the final converted history.

(As previously noted I expect the objects from the git-svn mirror should 
go in the new repository with the refs appropriately renamed, so that old 
commit hash references remain valid and people don't need to check out a 
separate repository to access old git branches, which should be doable 
with a single "git fetch" command; the two versions of the history would 
be disconnected, but most blob and tree objects would have the same hashes 
so this shouldn't enlarge the repository much.  Rebasing on top of the 
final conversion, for active branches currently git-only, would be 
preferred to anything that connects the two versions of the history.)

> E.g. having proper author names seems like a nice-to-have rather than
> a requirement.  A lot of the effort spent on compiling that list seemed
> to be getting names and email addresses for people who haven't contributed
> to gcc for a long time (in some cases 20 years or more).  It's interesting
> historical data, but in almost all cases, the email addresses used are
> going to be defunct anyway.

I think having author names and email addresses is a basic requirement of 
any reasonable repository conversion - it's simply how git identifies 
authors; having something that is not a name and email for the author / 
committer there is not a proper use of git datastructures.  For me, that 
means that, when the author and committer are the same, some name and 
email address for the author that are or were valid at some point should 
be listed for both those fields in git.

I'm not particularly concerned with distinguishing between different names 
and email addresses for an author depending on when or in what capacity 
they contributed a change, or with the cases where a patch was committed 
for someone else and SVN simply doesn't provide a way to distinguish that 
information.  However, since some people were concerned with that, and 
since the feature needed for that was implemented (the "changelogs" 
feature in reposurgeon, which will do it as long as a proper ChangeLog 
entry was included in the commit), we may as well use that feature.  (The 
author map is still needed for commits without ChangeLog entries.)

> The big advantage of Maxim's approach is that it's a public script in
> our own repo that anyone can contribute to.  So if there are specific
> tweaks people want to make, there's now the opportunity to do that.

reposurgeon is public code in its own repository.  So now is the 
conversion machinery using it.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Richard Earnshaw (lists)]

On 20/05/2019 23:42, Joseph Myers wrote:

> I'm not particularly concerned with distinguishing between different names 
> and email addresses for an author depending on when or in what capacity 
> they contributed a change, or with the cases where a patch was committed 
> for someone else and SVN simply doesn't provide a way to distinguish that 
> information.  However, since some people were concerned with that, and 
> since the feature needed for that was implemented (the "changelogs" 
> feature in reposurgeon, which will do it as long as a proper ChangeLog 
> entry was included in the commit), we may as well use that feature.  (The 
> author map is still needed for commits without ChangeLog entries.)
> 

For very old commits, back in the GCC 2 days, even the ChangeLogs don't
always show the author.  At that time only the committers' name was
used.  I'm pretty sure that some of my earliest patches to GCC were
committed by tege and kenner under their names.  So we'll never really
be able to fully reconstruct the early history.

R.

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Jeff Law]

On 5/21/19 8:24 AM, Richard Earnshaw (lists) wrote:
> On 20/05/2019 23:42, Joseph Myers wrote:
> 
>> I'm not particularly concerned with distinguishing between different names 
>> and email addresses for an author depending on when or in what capacity 
>> they contributed a change, or with the cases where a patch was committed 
>> for someone else and SVN simply doesn't provide a way to distinguish that 
>> information.  However, since some people were concerned with that, and 
>> since the feature needed for that was implemented (the "changelogs" 
>> feature in reposurgeon, which will do it as long as a proper ChangeLog 
>> entry was included in the commit), we may as well use that feature.  (The 
>> author map is still needed for commits without ChangeLog entries.)
>>
> 
> For very old commits, back in the GCC 2 days, even the ChangeLogs don't
> always show the author.  At that time only the committers' name was
> used.  I'm pretty sure that some of my earliest patches to GCC were
> committed by tege and kenner under their names.  So we'll never really
> be able to fully reconstruct the early history.
I'd say we make a reasonable effort here, but the importance of
authorship decays rapidly the further back we go.  Even when the author
(or committer) is still around, they often can't remember the details
around commits from that era.

jeff

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Richard Earnshaw (lists)]

On 21/05/2019 15:44, Jeff Law wrote:
> On 5/21/19 8:24 AM, Richard Earnshaw (lists) wrote:
>> On 20/05/2019 23:42, Joseph Myers wrote:
>>
>>> I'm not particularly concerned with distinguishing between different names 
>>> and email addresses for an author depending on when or in what capacity 
>>> they contributed a change, or with the cases where a patch was committed 
>>> for someone else and SVN simply doesn't provide a way to distinguish that 
>>> information.  However, since some people were concerned with that, and 
>>> since the feature needed for that was implemented (the "changelogs" 
>>> feature in reposurgeon, which will do it as long as a proper ChangeLog 
>>> entry was included in the commit), we may as well use that feature.  (The 
>>> author map is still needed for commits without ChangeLog entries.)
>>>
>>
>> For very old commits, back in the GCC 2 days, even the ChangeLogs don't
>> always show the author.  At that time only the committers' name was
>> used.  I'm pretty sure that some of my earliest patches to GCC were
>> committed by tege and kenner under their names.  So we'll never really
>> be able to fully reconstruct the early history.
> I'd say we make a reasonable effort here, but the importance of
> authorship decays rapidly the further back we go.  Even when the author
> (or committer) is still around, they often can't remember the details
> around commits from that era.
> 
> jeff
> 


Agreed, and I'm well aware of my limitation on remembering which of
those early patches were mine.  I was just pointing out that the
ChangeLogs from that period cannot be taken as an indication of authorship.

There's a fair chance that, if it was Arm related and dated from mid
1992 onwards, I had a hand in it.  But that's by no means a claim on all
such patches from that era.

R.

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Segher Boessenkool]

Hi Joseph,

On Mon, May 20, 2019 at 10:42:45PM +0000, Joseph Myers wrote:
> (SVN will remain 
> readonly, just as the old CVS repository remains available readonly).

> That the git-svn mirror is useful for many purposes for which people want 
> to use git also provides a clear argument against needing to do the final 
> conversion in a hurry;

Right.  But trying to correct the ancient history in the repo isn't useful
*anyway*.  One much bigger problem is that very often very unrelated things
are committed at the same time, in big omnibus patches.  Another much
bigger problm is that when you are doing the kind of archeology where this
matters, you need to have old the email archives anyway, which aren't
available.

> I think having author names and email addresses is a basic requirement of 
> any reasonable repository conversion

Yes, and they should be the same as they were in the original repository.


Segher

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Joseph Myers]

On Tue, 21 May 2019, Segher Boessenkool wrote:

> > I think having author names and email addresses is a basic requirement of 
> > any reasonable repository conversion
> 
> Yes, and they should be the same as they were in the original repository.

That's what the "changelogs" feature in reposurgeon does, when the commit 
that made the change also added a ChangeLog entry.

In the case where the commit didn't add a ChangeLog entry, a name and 
email address from an author map is the best we can practically do (and I 
think it's much better than having something that never was a valid name 
and email address for author or committer at all).  In particular, that 
applies to changes from the gcc2 tree (where ChangeLog wasn't version 
controlled at all until 1998, and after that didn't generally have log 
messages that could be matched up with those of the corresponding commits 
to other files).  Many of the names and addresses in the author map for 
the gcc2 repository *are* taken directly from the ChangeLogs (for some 
commit for each committer) as that was the most practical way of 
identifying who all the committers from that period were.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Segher Boessenkool]

On Thu, May 23, 2019 at 10:33:28PM +0000, Joseph Myers wrote:
> On Tue, 21 May 2019, Segher Boessenkool wrote:
> 
> > > I think having author names and email addresses is a basic requirement of 
> > > any reasonable repository conversion
> > 
> > Yes, and they should be the same as they were in the original repository.
> 
> That's what the "changelogs" feature in reposurgeon does, when the commit 
> that made the change also added a ChangeLog entry.
> 
> In the case where the commit didn't add a ChangeLog entry, a name and 
> email address from an author map is the best we can practically do (and I 

IMO the best we can do is use what we already have: what CVS or SVN used
as the committer identity.  *That* info is *correct* at least.

In many cases we can glance someone's real name from the changelog, sure.
People looking up things can trivially do that, and with much better
accuracy than any script can.  In some other cases you cannot, no matter
how hard you try.

> think it's much better than having something that never was a valid name 
> and email address for author or committer at all).

The fields in Git are just called "Author" and "Commit".  Not "real name"
or "email address" or anything like that.  It is just text.  Git does not
require anything specific about what you put here.


Segher

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Florian Weimer]

* Segher Boessenkool:

> On Thu, May 23, 2019 at 10:33:28PM +0000, Joseph Myers wrote:
>> On Tue, 21 May 2019, Segher Boessenkool wrote:
>> 
>> > > I think having author names and email addresses is a basic requirement of 
>> > > any reasonable repository conversion
>> > 
>> > Yes, and they should be the same as they were in the original repository.
>> 
>> That's what the "changelogs" feature in reposurgeon does, when the commit 
>> that made the change also added a ChangeLog entry.
>> 
>> In the case where the commit didn't add a ChangeLog entry, a name and 
>> email address from an author map is the best we can practically do (and I 
>
> IMO the best we can do is use what we already have: what CVS or SVN used
> as the committer identity.  *That* info is *correct* at least.
>
> In many cases we can glance someone's real name from the changelog, sure.
> People looking up things can trivially do that, and with much better
> accuracy than any script can.  In some other cases you cannot, no matter
> how hard you try.

Looking at the git fsck sources, I think you have to fake an email address:

        if (*p == '<')
                return report(options, obj, FSCK_MSG_MISSING_NAME_BEFORE_EMAIL, "invalid author/committer line - missing space before email");
        p += strcspn(p, "<>\n");
        if (*p == '>')
                return report(options, obj, FSCK_MSG_BAD_NAME, "invalid author/committer line - bad name");
        if (*p != '<')
                return report(options, obj, FSCK_MSG_MISSING_EMAIL, "invalid author/committer line - missing email");
        if (p[-1] != ' ')
                return report(options, obj, FSCK_MSG_MISSING_SPACE_BEFORE_EMAIL, "invalid author/committer line - missing space before email");
        p++;
        p += strcspn(p, "<>\n");
        if (*p != '>')
                return report(options, obj, FSCK_MSG_BAD_EMAIL, "invalid author/committer line - bad email");
        p++;

But something like “fw <fw>” would probably be acceptable.

Thanks,
Florian

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Joseph Myers]

On Fri, 24 May 2019, Segher Boessenkool wrote:

> IMO the best we can do is use what we already have: what CVS or SVN used
> as the committer identity.  *That* info is *correct* at least.

CVS and SVN have a local identity.  git has a global identity.  I consider 
it simply *incorrect* to put a local identity in a git committer or author 
- I think this is just like any other data format conversion necessarily 
involved in a repository conversion.  There's an argument that (real name 
from /etc/passwd on the repository system at the time of commit) plus 
(username @ hostname of repository system at the time of commit) 
corresponds most accurately to the old local identities, but we don't have 
the contemporaneous /etc/passwd and I don't see doing something like that 
as an improvement on using whatever each person's preferred identity for 
git commits is (or some name and email address we've found, in the absence 
of an expressed preference from a given committer), if there wasn't a 
ChangeLog entry added in that commit.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Segher Boessenkool]

On Wed, May 29, 2019 at 12:53:30AM +0000, Joseph Myers wrote:
> On Fri, 24 May 2019, Segher Boessenkool wrote:
> 
> > IMO the best we can do is use what we already have: what CVS or SVN used
> > as the committer identity.  *That* info is *correct* at least.
> 
> CVS and SVN have a local identity.  git has a global identity.  I consider 

Git has an identity (well, two) _per commit_, and there is no way you can
reconstruct people's prefered name and email address (at any point in time,
for every commit separately) correctly.  IMO it is much better to not even
try.  We already *have* enough info for anyone to trivially look up who wrote
what, and what might be that person's email address at the time.  But
pretending that is more than a guess is just wrong.

> it simply *incorrect* to put a local identity in a git committer or author 

On the contrary, the identity on the CVS or SVN server is 100% correct, and
it is the best we can do as far as I can see.


Segher

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Joseph Myers]

On Wed, 29 May 2019, Segher Boessenkool wrote:

> On Wed, May 29, 2019 at 12:53:30AM +0000, Joseph Myers wrote:
> > On Fri, 24 May 2019, Segher Boessenkool wrote:
> > 
> > > IMO the best we can do is use what we already have: what CVS or SVN used
> > > as the committer identity.  *That* info is *correct* at least.
> > 
> > CVS and SVN have a local identity.  git has a global identity.  I consider 
> 
> Git has an identity (well, two) _per commit_, and there is no way you can
> reconstruct people's prefered name and email address (at any point in time,
> for every commit separately) correctly.  IMO it is much better to not even
> try.  We already *have* enough info for anyone to trivially look up who wrote
> what, and what might be that person's email address at the time.  But
> pretending that is more than a guess is just wrong.

I think not doing a best-effort identification (name+email) is just as 
wrong as converting a CVS repository to a changeset-based system without 
doing a best-effort unification of commits to different files around the 
same time with the same log message into changesets.  Both are the same 
sort of heuristic conversion of data to the form idiomatic for a different 
version control system based around different concepts.  Neither is 
perfect, but the most useful conversion tries to combine CVS commits to 
different files into changesets, and the most useful conversion tries to 
identify authors in the way idiomatic for git using the information we 
have about what person (globally) a given username on a given system 
corresponds to.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Segher Boessenkool]

On Fri, May 31, 2019 at 12:05:41AM +0000, Joseph Myers wrote:
> On Wed, 29 May 2019, Segher Boessenkool wrote:
> 
> > On Wed, May 29, 2019 at 12:53:30AM +0000, Joseph Myers wrote:
> > > On Fri, 24 May 2019, Segher Boessenkool wrote:
> > > 
> > > > IMO the best we can do is use what we already have: what CVS or SVN used
> > > > as the committer identity.  *That* info is *correct* at least.
> > > 
> > > CVS and SVN have a local identity.  git has a global identity.  I consider 
> > 
> > Git has an identity (well, two) _per commit_, and there is no way you can
> > reconstruct people's prefered name and email address (at any point in time,
> > for every commit separately) correctly.  IMO it is much better to not even
> > try.  We already *have* enough info for anyone to trivially look up who wrote
> > what, and what might be that person's email address at the time.  But
> > pretending that is more than a guess is just wrong.
> 
> I think not doing a best-effort identification (name+email) is just as 

And I think guessing is not a "best effort", but just wrong.

> wrong as converting a CVS repository to a changeset-based system without 
> doing a best-effort unification of commits to different files around the 
> same time with the same log message into changesets.  Both are the same 

These are not similar situations at all.  Converting something to an SVN-
like data model is necessary for the resulting repo to work acceptably;
guessing person's names and email addresses is just nice-to-have in the
best case, and misleading in other cases.

> sort of heuristic conversion of data to the form idiomatic for a different 
> version control system based around different concepts.  Neither is 

It's single short line of text in SVN.  It is a single short line of text
in Git.  Both just show who wrote a patch, or who committed it.

Good luck finding out who was the primary author of every commit, btw.

> perfect, but the most useful conversion tries to combine CVS commits to 
> different files into changesets, and the most useful conversion tries to 
> identify authors in the way idiomatic for git using the information we 
> have about what person (globally) a given username on a given system 
> corresponds to.

We don't have that information.  This information can change over time,
and we never did track people's email addresses properly either.


Segher

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Joseph Myers]

On Sun, 2 Jun 2019, Segher Boessenkool wrote:

> > > Git has an identity (well, two) _per commit_, and there is no way you can
> > > reconstruct people's prefered name and email address (at any point in time,
> > > for every commit separately) correctly.  IMO it is much better to not even
> > > try.  We already *have* enough info for anyone to trivially look up who wrote
> > > what, and what might be that person's email address at the time.  But
> > > pretending that is more than a guess is just wrong.
> > 
> > I think not doing a best-effort identification (name+email) is just as 
> 
> And I think guessing is not a "best effort", but just wrong.

It's 100% accurate about the identity of the person who was the committer 
(modulo the one username from the gcc2 period where it was clear who the 
author of the commits by that username was, and so that went in the author 
map, but not clear that was the same as the committer, who did not commit 
patches for any other author).  So it's as accurate as any case where 
someone committing natively in git for someone else failed to use --author 
(and if the CVS/SVN commit included a ChangeLog entry, we have credit 
given from there via the "changelogs" feature).

I think failing to credit (by name and email address) the person implied 
by the commit metadata, in the absence of positive evidence (such as a 
ChangeLog entry) for the change being authored by someone else, is just 
wrong, in the same way it's wrong not to use --author when committing for 
someone else in git.

Where a person used different names over time, there's no generally 
applicable rule for whether they'd prefer the latest version or the 
version used at the time to be used in reference to past commits, and I 
think using the most current version known is most appropriate, in the 
absence of a ChangeLog entry added in the commit, unless they've specified 
a preference for some other rule for which commits get what name.  
Likewise for email addresses.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Segher Boessenkool]

On Mon, Jun 03, 2019 at 10:33:17PM +0000, Joseph Myers wrote:
> Where a person used different names over time, there's no generally 
> applicable rule for whether they'd prefer the latest version or the 
> version used at the time to be used in reference to past commits, and I 
> think using the most current version known is most appropriate, in the 
> absence of a ChangeLog entry added in the commit, unless they've specified 
> a preference for some other rule for which commits get what name.  
> Likewise for email addresses.

A common case is people changed employer.  Using someone's current email
address is just wrong.


Segher

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Jason Merrill]

On 6/3/19 6:33 PM, Joseph Myers wrote:
> On Sun, 2 Jun 2019, Segher Boessenkool wrote:
> 
>>>> Git has an identity (well, two) _per commit_, and there is no way you can
>>>> reconstruct people's prefered name and email address (at any point in time,
>>>> for every commit separately) correctly.  IMO it is much better to not even
>>>> try.  We already *have* enough info for anyone to trivially look up who wrote
>>>> what, and what might be that person's email address at the time.  But
>>>> pretending that is more than a guess is just wrong.
>>>
>>> I think not doing a best-effort identification (name+email) is just as
>>
>> And I think guessing is not a "best effort", but just wrong.
> 
> It's 100% accurate about the identity of the person who was the committer
> (modulo the one username from the gcc2 period where it was clear who the
> author of the commits by that username was, and so that went in the author
> map, but not clear that was the same as the committer, who did not commit
> patches for any other author).  So it's as accurate as any case where
> someone committing natively in git for someone else failed to use --author
> (and if the CVS/SVN commit included a ChangeLog entry, we have credit
> given from there via the "changelogs" feature).
> 
> I think failing to credit (by name and email address) the person implied
> by the commit metadata, in the absence of positive evidence (such as a
> ChangeLog entry) for the change being authored by someone else, is just
> wrong, in the same way it's wrong not to use --author when committing for
> someone else in git.

It's wrong, but it's not importantly wrong.  If we're doing a 
reposurgeon conversion, this adjustment makes sense.  If we're starting 
from the git-svn mirror, it doesn't justify breaking everyone's copies 
by rewriting branches.  And the bird in the hand looks more and more 
appealing as time goes by.

> Where a person used different names over time, there's no generally
> applicable rule for whether they'd prefer the latest version or the
> version used at the time to be used in reference to past commits, and I
> think using the most current version known is most appropriate, in the
> absence of a ChangeLog entry added in the commit, unless they've specified
> a preference for some other rule for which commits get what name.
> Likewise for email addresses.

For email addresses, I think that using @gcc.gnu.org would be the best 
approach for people that have such accounts, rather than an employer 
address from an arbitrary point in time.

Jason

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Richard Earnshaw (lists)]

On 05/06/2019 19:04, Jason Merrill wrote:
> On 6/3/19 6:33 PM, Joseph Myers wrote:
>> On Sun, 2 Jun 2019, Segher Boessenkool wrote:
>>
>>>>> Git has an identity (well, two) _per commit_, and there is no way
>>>>> you can
>>>>> reconstruct people's prefered name and email address (at any point
>>>>> in time,
>>>>> for every commit separately) correctly.  IMO it is much better to
>>>>> not even
>>>>> try.  We already *have* enough info for anyone to trivially look up
>>>>> who wrote
>>>>> what, and what might be that person's email address at the time.  But
>>>>> pretending that is more than a guess is just wrong.
>>>>
>>>> I think not doing a best-effort identification (name+email) is just as
>>>
>>> And I think guessing is not a "best effort", but just wrong.
>>
>> It's 100% accurate about the identity of the person who was the committer
>> (modulo the one username from the gcc2 period where it was clear who the
>> author of the commits by that username was, and so that went in the
>> author
>> map, but not clear that was the same as the committer, who did not commit
>> patches for any other author).  So it's as accurate as any case where
>> someone committing natively in git for someone else failed to use
>> --author
>> (and if the CVS/SVN commit included a ChangeLog entry, we have credit
>> given from there via the "changelogs" feature).
>>
>> I think failing to credit (by name and email address) the person implied
>> by the commit metadata, in the absence of positive evidence (such as a
>> ChangeLog entry) for the change being authored by someone else, is just
>> wrong, in the same way it's wrong not to use --author when committing for
>> someone else in git.
> 
> It's wrong, but it's not importantly wrong.  If we're doing a
> reposurgeon conversion, this adjustment makes sense.  If we're starting
> from the git-svn mirror, it doesn't justify breaking everyone's copies
> by rewriting branches.  And the bird in the hand looks more and more
> appealing as time goes by.
> 
>> Where a person used different names over time, there's no generally
>> applicable rule for whether they'd prefer the latest version or the
>> version used at the time to be used in reference to past commits, and I
>> think using the most current version known is most appropriate, in the
>> absence of a ChangeLog entry added in the commit, unless they've
>> specified
>> a preference for some other rule for which commits get what name.
>> Likewise for email addresses.
> 
> For email addresses, I think that using @gcc.gnu.org would be the best
> approach for people that have such accounts, rather than an employer
> address from an arbitrary point in time.

Or @gnu.org for accounts that pre-date the switch to EGCS and CVS.

> 
> Jason

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Joseph Myers]

On Thu, 6 Jun 2019, Richard Earnshaw (lists) wrote:

> > For email addresses, I think that using @gcc.gnu.org would be the best
> > approach for people that have such accounts, rather than an employer
> > address from an arbitrary point in time.
> 
> Or @gnu.org for accounts that pre-date the switch to EGCS and CVS.

When were such addresses introduced?  I'm not sure if all the gcc2 
committers would have had them, or only @<some-machine>.ai.mit.edu if 
that's where the repository was (certainly many early ChangeLog entries 
tend to use the <some-machine>.ai.mit.edu form, if not just 
<some-machine>).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Ian Lance Taylor]

On Thu, Jun 6, 2019 at 4:41 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 6 Jun 2019, Richard Earnshaw (lists) wrote:
>
> > > For email addresses, I think that using @gcc.gnu.org would be the best
> > > approach for people that have such accounts, rather than an employer
> > > address from an arbitrary point in time.
> >
> > Or @gnu.org for accounts that pre-date the switch to EGCS and CVS.
>
> When were such addresses introduced?  I'm not sure if all the gcc2
> committers would have had them, or only @<some-machine>.ai.mit.edu if
> that's where the repository was (certainly many early ChangeLog entries
> tend to use the <some-machine>.ai.mit.edu form, if not just
> <some-machine>).

I got a @gnu.org account around 1990 or 1991, and I was hardly the
first, so they were introduced some time before then.

Ian

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Richard Earnshaw (lists)]

On 07/06/2019 00:50, Ian Lance Taylor wrote:
> On Thu, Jun 6, 2019 at 4:41 PM Joseph Myers <joseph@codesourcery.com> wrote:
>>
>> On Thu, 6 Jun 2019, Richard Earnshaw (lists) wrote:
>>
>>>> For email addresses, I think that using @gcc.gnu.org would be the best
>>>> approach for people that have such accounts, rather than an employer
>>>> address from an arbitrary point in time.
>>>
>>> Or @gnu.org for accounts that pre-date the switch to EGCS and CVS.
>>
>> When were such addresses introduced?  I'm not sure if all the gcc2
>> committers would have had them, or only @<some-machine>.ai.mit.edu if
>> that's where the repository was (certainly many early ChangeLog entries
>> tend to use the <some-machine>.ai.mit.edu form, if not just
>> <some-machine>).
> 
> I got a @gnu.org account around 1990 or 1991, and I was hardly the
> first, so they were introduced some time before then.
> 
> Ian
> 

Well, according to CVS, the only accounts to make commits to GCC before
the end of 1990 are

 mycroft
 rms
 roland

And if you go to the end of 1991, it only adds

 meissner
 kenner
 dennisg
 wood
 tiemann
 wilson
 jrv

so it wouldn't be a major job to special case those if really necessary.
 I would imagine that gnu.org inherited the majority of user names from
prep when the domain was split off, so the precise dates probably don't
matter to much.

R.

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Joseph Myers]

On Wed, 5 Jun 2019, Jason Merrill wrote:

> > I think failing to credit (by name and email address) the person implied
> > by the commit metadata, in the absence of positive evidence (such as a
> > ChangeLog entry) for the change being authored by someone else, is just
> > wrong, in the same way it's wrong not to use --author when committing for
> > someone else in git.
> 
> It's wrong, but it's not importantly wrong.

I think it's importantly wrong not to have a name and email address for 
the committer in the absence of using such information for the author.  
(Whereas if the name or email address refer to the right person but are 
anachronistic for that commit, that's what I'd consider not importantly 
wrong.)

> For email addresses, I think that using @gcc.gnu.org would be the best
> approach for people that have such accounts, rather than an employer address
> from an arbitrary point in time.

I'm fine with use of @gcc.gnu.org (used together with a name for the 
person in question that is or was valid, at or after the time of some 
commit they made) for committers who in fact do have or did have such an 
address (as opposed to inventing such addresses for committers from the 
gcc2 era who never had such addresses, or anyone who only committed in the 
egcs.cygnus.com era and who no longer had an account by the time of the 
move to gcc.gnu.org).

When the commit adds a ChangeLog entry and thus contains contemporaneous 
information about the preferred name and email address for the author at 
that time, I think using that information (via the reposurgeon 
"changelogs" feature) is preferable to a generic author map entry (thus, 
the author map entries should be considered a fallback for those commits 
that didn't add a ChangeLog entry (or added one with bad syntax for which 
parsing fails, etc.)).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

[-- Attachment #1: Type: text/plain, Size: 3228 bytes --]

> On Jun 7, 2019, at 2:36 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> On Wed, 5 Jun 2019, Jason Merrill wrote:
> 
>>> I think failing to credit (by name and email address) the person implied
>>> by the commit metadata, in the absence of positive evidence (such as a
>>> ChangeLog entry) for the change being authored by someone else, is just
>>> wrong, in the same way it's wrong not to use --author when committing for
>>> someone else in git.
>> 
>> It's wrong, but it's not importantly wrong.
> 
> I think it's importantly wrong not to have a name and email address for 
> the committer in the absence of using such information for the author.  
> (Whereas if the name or email address refer to the right person but are 
> anachronistic for that commit, that's what I'd consider not importantly 
> wrong.)
> 
>> For email addresses, I think that using @gcc.gnu.org would be the best
>> approach for people that have such accounts, rather than an employer address
>> from an arbitrary point in time.
> 
> I'm fine with use of @gcc.gnu.org (used together with a name for the 
> person in question that is or was valid, at or after the time of some 
> commit they made) for committers who in fact do have or did have such an 
> address (as opposed to inventing such addresses for committers from the 
> gcc2 era who never had such addresses, or anyone who only committed in the 
> egcs.cygnus.com era and who no longer had an account by the time of the 
> move to gcc.gnu.org).
> 
> When the commit adds a ChangeLog entry and thus contains contemporaneous 
> information about the preferred name and email address for the author at 
> that time, I think using that information (via the reposurgeon 
> "changelogs" feature) is preferable to a generic author map entry (thus, 
> the author map entries should be considered a fallback for those commits 
> that didn't add a ChangeLog entry (or added one with bad syntax for which 
> parsing fails, etc.)).

I've uploaded first version of "pretty" trunk [*] with author information re-written in commits.  Please take a look and comment.

The approach I used:
1. Start with SVN $userid -> $name mapping from https://gitlab.com/esr/gcc-conversion/blob/master/gcc.map .
2. For every $commit look through "git log -p $commit" history and try to find first occurrence of "$name <some@email.com>" [**]
3. If successful, update $userid -> $name -> $current_email mapping
4. Use latest entry for $userid -> $name -> $current_email mapping.  If no such entry exists, use $userid@gcc.gnu.org for email address.

This approach tries to take account of people switching companies and changing their names.

The resulting mapping is attached.  Please let me know if you spot any mistakes in it.

Entries with sha1 hash in them like
mycroft = Charles Hannum (a1c19ad21c0fb2395a2793cb4b9db71528a51c8e)
mean that the script was not able to find "Charles Hannum some@email.com" in the entire "git log -p $sha1" history.

[*] https://github.com/maxim-kuvyrkov/gcc/commits/trunk-pretty
[**] The actual regex is sed -e "s#.*$name[ <(,\t]\+\([0-Z\._-]\+@[0-Z\._-]\+\.[0-Z_-]\+\).*#EMAIL: \1#" .

--
Maxim Kuvyrkov
www.linaro.org


[-- Attachment #2: authors.map --]
[-- Type: application/octet-stream, Size: 190745 bytes --]


no-author = No Author (3cf0d8938a953ef13e57239613d42686f152b4fe)
mycroft = Charles Hannum (a1c19ad21c0fb2395a2793cb4b9db71528a51c8e)
mycroft = Charles Hannum (17cf341d65a3766f6451fe3bc20b9c010d38ba3b)
mycroft = Charles Hannum (8f77ae7fd2ec045a58d1b1557e1e0a7731bf0e32)
mycroft = Charles Hannum (dde24f037df159606b663951d5effe8822b66d80)
mycroft = Charles Hannum (c4992c7c47f839a789212e140710d0fc192ed2df)
mycroft = Charles Hannum (16220ae3eedcc1485844b8d2f0c3cdf4ff9f565c)
mycroft = Charles Hannum (056f54e5c0dc5fa3c9f20fcabc6dd18f7e9c0491)
mycroft = Charles Hannum (994b0f80aa6b084f6675f1e0a3e1fc859f5a7077)
mycroft = Charles Hannum (34af06d14eedc1220bfb44a3a49eb71d1cd7655c)
mycroft = Charles Hannum (bed4d7330952fc8812d9cdc96dba4fd7735c6eb7)
mycroft = Charles Hannum (2bbfbd4bea3f5f5f02676fe90ddcf928203c5d46)
mycroft = Charles Hannum (bb1df06fae3d4f38d4de2b6107792cbcdb6a8154)
meissner = Michael Meissner <meissner@osf.org>
mycroft = Charles Hannum (df081f772bd51c5fbb028e490f12188330158e2e)
mycroft = Charles Hannum (1e5eef617713bea388d10b957d8002cb2f42eda3)
mycroft = Charles Hannum (d9762eebed554fabf14c59799ab9f7b0665d6e0b)
dennisg = Dennis Glatting (acfeb7b74f18c808a612322dd2484d762d93e56a)
dennisg = Dennis Glatting (46117fc8a857431f7466ad1fb7925cc6e7352bd9)
kenner = Richard Kenner <kenner@nyu.edu>
mycroft = Charles Hannum (923c7aac7950e80dbfca995210262bb48654958c)
dennisg = Dennis Glatting (d4deae866c83281c03eb7b433699dcdabc29b291)
dennisg = Dennis Glatting (01a6b9a742b9bd934938044a28d31ffbe35053a7)
dennisg = Dennis Glatting (34282124bee1a07adf25d6111bc6edbbc19f455a)
dennisg = Dennis Glatting (1c26a84dc9e099aefc3ed426d64f48a71b295bbb)
dennisg = Dennis Glatting (c9c1dcb8c98b82e6cb93c0442c9eb6ca72009845)
dennisg = Dennis Glatting (f3a6b508c28045bd29f488cf442eb130b6d94ace)
dennisg = Dennis Glatting (9d4c6634c695c1ebb3d6597a760daf9d475cbc1d)
dennisg = Dennis Glatting (d4deb8945d6908a5f561a1c94f65a424528022f1)
dennisg = Dennis Glatting (53530cd91498d9ea68078b0b5bec2aed2eeb28df)
dennisg = Dennis Glatting (3f81a9979461809d13d6dc1a49ca45dba04b94a3)
dennisg = Dennis Glatting (d78a6512236ff6a4e2a72270a985ca9bdfbcd2fd)
dennisg = Dennis Glatting (8ac4e72f79429a6792de6074f1f1e8a1d2b33810)
mycroft = Charles Hannum (40df7ddb2984e840fb03fd545d8a6992836a3a1f)
mycroft = Charles Hannum (29a704c747eee7dd0d376e81931cc65ff8fc05bf)
dennisg = Dennis Glatting (a1d3ff3b6afe2f96f459d2d634336be6155041cd)
dennisg = Dennis Glatting (d207199e114ad37502d845e2d950f67d9cff8732)
dennisg = Dennis Glatting (038b867ff93a45f098327466d000773b3f294401)
dennisg = Dennis Glatting (a5375da668f3d59cd72fe1351354ced88b42791d)
mycroft = Charles Hannum (26766eee471004f07a47eb0b2058d9cfd8156d97)
mycroft = Charles Hannum (bb01a06e6cdd8c543600813f0e01cf9ad5a1076c)
mycroft = Charles Hannum (dca0cb28edcfcdf728467e1b5338ad9fe7418ece)
dennisg = Dennis Glatting (baefe8c0e7cdba4d6227aa4cd776e655a0549381)
tiemann = Michael Tiemann <tiemann@cygnus.com>
mycroft = Charles Hannum (ca6ffdb320f73499e2e2bff4ef69f33d0e3e41cf)
dennisg = Dennis Glatting (9f6010db6b9c09bf89442540236acfef04b99802)
mycroft = Charles Hannum (2dca73b6d8c83d19c5eee92622f6707ace5bdd96)
mycroft = Charles Hannum (5d4174e6bafd5839f3b26df4ca1706a3ca867bf2)
mycroft = Charles Hannum (05e25db608d55c01681d3104a518bc4d74b3aa14)
jrv = James Van Artsdalen (535825e69a252f305fbdbb98a0a928ad06d52f02)
dennisg = Dennis Glatting (f3919e1665efe61923a998a12f3839fd427fc492)
dennisg = Dennis Glatting (8708f04518bf76edc3c4cc96122e664bfa8b5fe1)
wood = Tom Wood <wood@dg-rtp.dg.com>
mycroft = Charles Hannum (ea3a6df6a9c21919cd465111df6710a2eede3581)
mycroft = Charles Hannum (4b0f9a110338830342a0c42daeda125caace17ea)
mycroft = Charles Hannum (0bf7d3c95f9191f4fdbcd7b1f3c01c56ac565a97)
mycroft = Charles Hannum (b50e273dc98b0b1c0196f51414958855c78487df)
mycroft = Charles Hannum (539a75a2a88cb4e48e541ffcf6e8f21ed26f2593)
rms = Richard Stallman <rms@ai.mit.edu>
jrv = James Van Artsdalen (4b639f5709d8bd750c1a58e7f4f2cda0ff08514f)
mycroft = Charles Hannum (25149b4382a82a3db18739fec5d3a39aa5f5d81d)
jrv = James Van Artsdalen (38fc2180c763bd5fe753000b6332f82f02242555)
jrv = James Van Artsdalen (53d548f5ab7bda50df5534b1c8dd3d635fd6c982)
mycroft = Charles Hannum (a5dacc9b13aa5e8152dcf310fc6da24e7c1ca58e)
jrv = James Van Artsdalen (43b83681c978f73094fcd79bbc9558dcb8d88977)
mycroft = Charles Hannum (bc2bb0825c4085eb873eb74d4a9f80e349b88cb5)
mycroft = Charles Hannum (1c6899c59d2fde57f814a9eb2ae8e414ecaac2a4)
cks = Chris Smith <csmith@convex.com>
mycroft = Charles Hannum (637bf27fd3d780e2bff61441ba97c8a22882d365)
wilson = Jim Wilson <wilson@cygnus.com>
jrv = James Van Artsdalen (762faee482ca19ade1ad53da791fd7a4b43f5cde)
djm = David J. MacKenzie (9ec1a94da91d6e175e75a9bb893a048495cd3f98)
jrv = James Van Artsdalen (70e168241d4de4cc487e202db2074bbda63cacfe)
jrv = James Van Artsdalen (ff5ef762a364dad7a27e1f08e6238e129adbdacf)
mycroft = Charles Hannum (5fd29b35c2cad01fab9ffd383d6d1377bd01e086)
jrv = James Van Artsdalen (5d70629f550969d9507f7ff52211ab7dfe38df8b)
djm = David J. MacKenzie (2e5d8ef90be3f784e081b6c3e80f0dc58a7a8c1f)
mycroft = Charles Hannum (86f22339af573ef79e7bd7d7267f50d307b9cdfe)
djm = David J. MacKenzie (5fe49652ce13412600fef79ff8d87358403e26b2)
jrv = James Van Artsdalen (4e82a1e7ba226813e0e95346aea9fdf57312e67b)
jrv = James Van Artsdalen (945773ae46fe316fc668c27bafbd42547e72265c)
mycroft = Charles Hannum (1baf4c4db958ad7735cad3f962fbc69055bd1cf2)
mycroft = Charles Hannum (c3057fefe11e894cb31a87da063cab4cd0809114)
mycroft = Charles Hannum (7d946265e5a864043603e761d9c78aff66bead2f)
mycroft = Charles Hannum (966e4333fe31ffa43cf1e59be7d40d5c2f963f54)
mycroft = Charles Hannum (c17b0569226bd975e9ae6b47682fd6ad561987f9)
mycroft = Charles Hannum (8cd42699c463f3f0bcff49021bee0e0a8676bba9)
mycroft = Charles Hannum (390f298a6386d4cdb038468c9881f3d98ff551f4)
jrv = James Van Artsdalen (2bec61803863c978ac4f9abc3606851d0cde4591)
mycroft = Charles Hannum (a8b07a64ca855fa77f1551c33927b1c1e970e633)
jrv = James Van Artsdalen (5e7d3bd1966732972ab17f0f5f26b0a8d42cee8b)
jrv = James Van Artsdalen (fc738e1dd670a1c0377d462d488b7e0cab8da6a7)
raeburn = Ken Raeburn <Raeburn@Watch.COM>
mycroft = Charles Hannum (58c9c9fc5aafdb35f96b96cbd7a6ae20db8b37cb)
jrv = James Van Artsdalen (e5a5e6a9aa3c4222b0a18ccada07a6db734c4543)
mycroft = Charles Hannum (4e2c2e708bea88a0aa098f81237f502fc304180a)
jrv = James Van Artsdalen (cd52197afd6ad5412f774dafa065d2baa08994c9)
mycroft = Charles Hannum (82762be81a5715c042e55777fb6cc58e29403eab)
moore = Timothy Moore (019a49c61029dde89feda499da570ec6e04861a0)
bothner = Per Bothner <bothner@cygnus.com>
mycroft = Charles Hannum (50118dc36d470775775cf276344507e2dc8174ef)
mycroft = Charles Hannum (9a8e6e520a2ba3690ff62c8f7d959ca8d4973a2b)
jrv = James Van Artsdalen (9951570c0177bcfd31180a6e5b9afd980aa564b9)
mycroft = Charles Hannum (305b46b3436c143e52f7cc81d1b6cccfda4b9702)
jrv = James Van Artsdalen (412bc76382d6e58a531fbf6371d24dddf3625594)
jrv = James Van Artsdalen (2ef1e405b5e23bda61b4f2e9c670b4ebd73480d3)
dennisg = Dennis Glatting (77eb838e0066cdf64671e63f3d03f0e8ad5b4aae)
mycroft = Charles Hannum (baa93cacac31319cd4cd8a7b23be43a2ab57d53e)
jtw = John Wroclawski (d7acad9f74dfc81a6be59196a84640035692df1e)
mycroft = Charles Hannum (b172114d3d2c17f57611e68d1905ec5ac8938163)
mycroft = Charles Hannum (bd6c3307170e2eaa4bbe96ae0b2a207f0cd68be5)
mycroft = Charles Hannum (629a5b0f8a9ddcf4b27467ff89cac230cffba34a)
jrv = James Van Artsdalen (b15e0bba005f961471fb171fe5966cb68baee8ea)
jrv = James Van Artsdalen (d63e6e89b2d1922bc9c59e689fe3b485c86ad898)
jrv = James Van Artsdalen (2420af7dbc6c15ffc775530ff4d0e62119325624)
mycroft = Charles Hannum (b1388a865969409dddb0146862d03eb54d3c87cc)
jrv = James Van Artsdalen (f6571fe0927577288c13868351a2917a2fcefa91)
jrv = James Van Artsdalen (a5fd10b48fc421ac466e2b580e3f2ff99af50307)
mycroft = Charles Hannum (570ea49cca5e5cfa823673dc09dca81f05dc0020)
jtw = John Wroclawski (5dfd39ad4997d354c4414c00a030f8217b4d31c5)
mycroft = Charles Hannum (87a66107be6a6c7bc7648fff6275c7844bf351b8)
mycroft = Charles Hannum (9c139aa082976be7d60fdbb909e0ff35f4d990aa)
mycroft = Charles Hannum (f0e22b4ea622717f357a44f04d568461de30b47d)
jrv = James Van Artsdalen (0d3b804ec89f121cd459f64aaa83f48f9a8ed952)
mycroft = Charles Hannum (a019fca5af890df0279655b7a33c9b6dad0f9a26)
jrv = James Van Artsdalen (d8bd43694ef771bb5e58f0ddd54bbb622b11271d)
mycroft = Charles Hannum (4f15720ca9c647eb7998dfdec1d847823765ce16)
jrv = James Van Artsdalen (6ea8310776f82d06c6647212fd21c75b86b0cdfd)
mycroft = Charles Hannum (b7b4a1139ffb6002e3cf6c599876326c8644deaa)
mycroft = Charles Hannum (5719804ea267dfc4bf3a46ec4d50514208c1c023)
mycroft = Charles Hannum (1049378a2965771066b5458f3df2f7bdd7cbfc16)
mycroft = Charles Hannum (c019aa1abe5509599575a43791897c592854d687)
mycroft = Charles Hannum (5ac13a47ab376ac014d54e81734a33972045a750)
jrv = James Van Artsdalen (af0bbefa03805b21cf470805d7c4ccf023e88a8f)
jrv = James Van Artsdalen (fae3730e9fe77f1f98fb0dc2fd7575983b41a91f)
mycroft = Charles Hannum (9a37111c6d07b4fcf96c55a4645497e66f24989e)
mycroft = Charles Hannum (34ed2989b0d628e04816d57d38f08fd2c9d9fc84)
jrv = James Van Artsdalen (c038f23476b2f3133b9cd8df2a278e314d620282)
mycroft = Charles Hannum (2726d786abd363a44b8e765ca869a4bd607b9e92)
mycroft = Charles Hannum (5dd605c6269e243d8730f8651eb2fa05a3097d57)
mycroft = Charles Hannum (beb321c72cdcdc82b992982cb5de3e1af54540f9)
mycroft = Charles Hannum (ceb855c5615d9968027d460d2152bd48e7e0ce07)
mycroft = Charles Hannum (6262d0336481b9705896c03d8c957a0310fe8266)
mycroft = Charles Hannum (69e84dfa8697c44fd84aab88a9245abbba6795c2)
mycroft = Charles Hannum (b3c0371ff67af674fc4b69f0a2244252c2aa3805)
mycroft = Charles Hannum (baef9648c251f5ae80b4166b2c1727f6b167263f)
mycroft = Charles Hannum (ec0d1e5194f3156c78b1c67383befc0b9f6753a3)
mycroft = Charles Hannum (bedd5a66a6cd142b016a8b8d44a8a4c002cea8a6)
mycroft = Charles Hannum (4b5446d126ce33e92fac4381c15cece13fd328a4)
mycroft = Charles Hannum (18fb9242088a93b74dc8637282c3abecfeb11d05)
mycroft = Charles Hannum (171493acfb27a3afeb352630c08943d1c818e207)
mycroft = Charles Hannum (69820a4d121ed05baaaac2f1c4361b8ff20d9454)
mycroft = Charles Hannum (a840ff962cb1c672191a7ef616132d1c8af81512)
mycroft = Charles Hannum (e4ce9fd3918ae3db99e99828259d251565604a51)
mycroft = Charles Hannum (a07abb90123719d2426cc9b92e2fa9fcbc727c55)
mycroft = Charles Hannum (ad13189dd6721a9db0fdc6ce77e714238cefc9c1)
mycroft = Charles Hannum (de5dfa718b090c8dd9ab272a53f0d2e953e19fb5)
mycroft = Charles Hannum (0a3e6aa0efe129078ae2114407bfc8da70f38a23)
mycroft = Charles Hannum (0db7b740ef2d90da6ce4f64bd6fd8b1c1c8d032d)
mycroft = Charles Hannum (d15484a6baa15df6321c1933b6b45f5a012bbddc)
mycroft = Charles Hannum (2903287c9e9794c8026458a2c3b79e6f49e68e10)
mycroft = Charles Hannum (7ebbec245abf18c30f987b7f4d608fffe7125ba0)
mycroft = Charles Hannum (6a1a98913960ac9c4a2873011f8c5377c9fd3067)
mycroft = Charles Hannum (1789ac090dbcdd5d499a443fd1ba990c0d21b576)
mycroft = Charles Hannum (b441e6f1598ee1e515149a0824a6ec4af833c88f)
mycroft = Charles Hannum (7d20ccb6d69d327bbfc5f75b7049d84f5f860f7a)
mycroft = Charles Hannum (cd8c1d21a05193ca2ff5f96e1878385715b95593)
mycroft = Charles Hannum (77190214ef5fc03d51f6930b5cfae374c9d4a8ef)
mycroft = Charles Hannum (c58bc47a5174c3708e78cbe5969cb5bc9d071586)
mycroft = Charles Hannum (4d3281c9f3e89daa7f3929a7dc4678b9809931ac)
mycroft = Charles Hannum (51d7935fdbbe5ba59f6a087fb1fcff84f65d5b12)
mycroft = Charles Hannum (b71d6f6196f837b3c5431dea843b61971545fdba)
mycroft = Charles Hannum (6302fdead45591b6c91b92998f4918e4f97c9161)
moore = Timothy Moore (35933a0790fea75ffe3fc55dedc326acc2d30d23)
mycroft = Charles Hannum (60c4847b1dea5065c9111dff4a75cbd2fadd0254)
mycroft = Charles Hannum (6207bd2cfa283c3adc4edff9056f34198fb03a10)
mycroft = Charles Hannum (1bb047289a4a7728316db4052deed7dc8c119dbc)
mycroft = Charles Hannum (50b0c9eea40827040e42434e288298507f567ce7)
mycroft = Charles Hannum (e5fdd56480a01373808ac2d66b9da52bd3388fd1)
mycroft = Charles Hannum (d3115c9016ed0fd89d6c951a2ed8bfe013af49a7)
mycroft = Charles Hannum (9a85dd20131f7c623688fa28f251eaa7ff9b73a4)
mycroft = Charles Hannum (8ffc504d4b29947cd25d0effc0e6395c840a2c71)
mycroft = Charles Hannum (b5505acf72c9059f9a22c86a3a4e6ca844ed2420)
mycroft = Charles Hannum (8afcf59300b5066adb97bcb2e013f5461fe35cfe)
mycroft = Charles Hannum (ce7685fa45ac9fa73fc56e451790badcdfb87990)
mycroft = Charles Hannum (b86836bdce7831ab19d0581e5e7f49d34656c683)
mycroft = Charles Hannum (35bb04fcfd43fd90dfcdec814868018ba4e86726)
mycroft = Charles Hannum (e581c4fc3f4ec03d70e2a85fdafa10d7014a642f)
mycroft = Charles Hannum (bd3c175de96fb6d3a1d88e17dd8c9f58245ec680)
mycroft = Charles Hannum (64d39272be1c0d638905a41c291f716b93c4b1c7)
mycroft = Charles Hannum (3ec1fc1bd6371df48653a30c6cedd14c90221ad7)
mycroft = Charles Hannum (0aab1048ef88f6b7666b53b2e24fb6c2091af000)
mycroft = Charles Hannum (1adc1592c017d690ba09973b0c30aeadd337b463)
mycroft = Charles Hannum (9f3574e39b319494674eb781d8de862b81e5467a)
mycroft = Charles Hannum (76e4a18bcf66591f092c6d2efc0770bd70706846)
mycroft = Charles Hannum (918d2e295d59286df1a6a67f119682e3cb66c81c)
mycroft = Charles Hannum (f7a758103e01ef44772fa9255c15e9b55ad6ac3f)
mycroft = Charles Hannum (80f6ed33ba01432cbf280aa1abd7dd5474ce60fb)
mycroft = Charles Hannum (7e724f9359a54c9203ba62c7df068237819b0bc9)
mycroft = Charles Hannum (84bf2ad1b5c64de583157d2f6488b54d274beb83)
mycroft = Charles Hannum (4b8f50a8692ae1e3f4e7272195b1082c62825e20)
mycroft = Charles Hannum (a6b5e7ff314b348d13f3ff5ea40b6cc473e15c8d)
moore = Timothy Moore (a7ae68994011bb475bd2e736c08bd5470ede1a24)
moore = Timothy Moore (b16ce056a6f3e7fd7ba78ba8b9e796f9dc174fbe)
moore = Timothy Moore (9c6d48252857dda6be55a60986ba456af796837f)
dglattin = Dennis Glatting (4c865481469564aae7ab4af11313c8d948c4808c)
jrv = James Van Artsdalen (0370c59727df6bb24051c5c31cb8ae630125281f)
jrv = James Van Artsdalen (914f028f12659bfd10fb60e4f0d7c4707f5ca06c)
jrv = James Van Artsdalen (a73a854791e0628018cbb591cabecabe02f1c067)
jrv = James Van Artsdalen (f0a544524083787ff0fc692ed857c800ce9f991c)
jrv = James Van Artsdalen (d315aa962016c0720103280c017ebb6472018ddd)
jrv = James Van Artsdalen (4581c90c5b8d880092e62eecc275517d4c82b1da)
jrv = James Van Artsdalen (40c383df25ba693847f1ed61b1207cb5eb2ec4a0)
jrv = James Van Artsdalen (34fd3bd011cdd7060f043cf212c6a3d95d9bc031)
jrv = James Van Artsdalen (6ff667f42211441aed48363496321ec02b1f42cd)
jrv = James Van Artsdalen (990c162694df53e934295a663edd35b2386aaac1)
jrv = James Van Artsdalen (a33c211d1d007de604ceef857a54ea8703681481)
jrv = James Van Artsdalen (9ed5d211e9fa1532188052e7e4139d3cc8895443)
jrv = James Van Artsdalen (fcbe7389950f732fcb88aa9cb7903dda53a7b8fa)
jrv = James Van Artsdalen (914a34d6d52a49186e04560f325c798a757f4fcc)
dglattin = Dennis Glatting (221570aaa1bf7ec603b87411b792fb330da65ce3)
dglattin = Dennis Glatting (a89af13115e28e6e5b3b3972c0f47b7656e234e3)
dglattin = Dennis Glatting (68ab56750a033cda408d4faff80e4494948e3025)
moore = Timothy Moore (71890292b90197e198b56d53f52a37d0f0134eda)
jrv = James Van Artsdalen (99e44cc8c4a6841e2e4eff742166cada411c8128)
moore = Timothy Moore (30cf270f3955add7ce9f0b1946ef8341326213c2)
moore = Timothy Moore (7e08d3b0bacefc2f979fbd411930093679b2a1d6)
moore = Timothy Moore (c40fc983ad77aabe604160e3678f4dd08e987602)
moore = Timothy Moore (fd004d82d76aab2c057a79e2d9390a01d0500d92)
jrv = James Van Artsdalen (f2cab2c230dab49eeaa7141c45029253106b485b)
jrv = James Van Artsdalen (47bebe109c91ab9d1f0aea99132be3d90fcc4b9a)
moore = Timothy Moore (b7740332cd0813d33477c0bb7a9c884cd7aa385b)
moore = Timothy Moore (33e281af4842cc8692bc13d82c66d673696abeb9)
moore = Timothy Moore (5d22b08fa5ab891f30dbbea0702da7d29ffb3805)
mycroft = Charles Hannum (b19bcbd67a278b21083ed05e7124c466526fa3df)
jrv = James Van Artsdalen (1445563af2a3e1995845a500ba8c773467afaa4f)
rolfh = Arne H. Juul (a953974ca720f5893332fd4ee11acebaee00af60)
jrv = James Van Artsdalen (bf676acc079265df683c4685c8555e60d98eeffe)
jrv = James Van Artsdalen (32df3b6c384fa36cdbe369c84c334bbe42ade2dc)
jrv = James Van Artsdalen (d1deac2539c7dbf50f1429c8bd768698f81b75a9)
jrv = James Van Artsdalen (65fe2beaf31baafb935e892dff1994edf63f0f50)
jrv = James Van Artsdalen (78f42230dbdb65a0681c439b4cd1346c75e8e738)
jrv = James Van Artsdalen (9efd3a9b16f3a938b4e82a80819e522146b73176)
jrv = James Van Artsdalen (4101be691cb39d0b7f07c68e8c0b1d1029d13066)
jrv = James Van Artsdalen (57ee9f57e7c2f510a53c34a43dbc13c030390100)
jrv = James Van Artsdalen (92102c7df2a2b76d173a9b98496f50fba469d302)
moore = Timothy Moore (1e90975ffff926d401a47eacaf8baa752936b289)
moore = Timothy Moore (d6f015258eec6c08a31adf10606aef0bff65452e)
moore = Timothy Moore (3ddcbb9d3fbd82fe3b7b8171a615bebb5e9136b7)
moore = Timothy Moore (68b21d10fa668878c75022ca61ddc1e3db368ea0)
mrs = Mike Stump <mrs@cygnus.com>
rolfh = Arne H. Juul (553479e8e669c06e2c80ac630f033420056ff589)
moore = Timothy Moore (d928851f1c49fb4a17a3d4a4756f921861cb5904)
moore = Timothy Moore (c1b3411eab368ad73b301df1af56ce8c58dedd92)
moore = Timothy Moore (f34112542cf963d8c30a9684792ba36663f07ca5)
jrv = James Van Artsdalen (e0d5e70f4a5d03f326c76c3bdc28ec0bf3d4e7fb)
jrv = James Van Artsdalen (40ba45e88caa23d1ef703726b928e07fc425cbae)
jrv = James Van Artsdalen (c942d0d14bfd7317b1da999d162069e751c0b05e)
jrv = James Van Artsdalen (a482e5cf7da3bc182709647f6b590071e7e274f3)
jimb = Jim Blandy <jimb@totoro.cs.oberlin.edu>
jrv = James Van Artsdalen (974d0446dd55c908c6fa6e25c40e15148f91f72c)
wood = Tom Wood <Tom_Wood@NeXT.com>
jrv = James Van Artsdalen (7372e532225bfe4c8b4bd9e46b580262d80650b4)
jrv = James Van Artsdalen (28b4c989b879f2bcb94e2ed8b18b2310c993d4aa)
jrv = James Van Artsdalen (34caabe915d9dce974b6ab5e19ef054f490a00c2)
jrv = James Van Artsdalen (16ece14087e3be808d3275bd52e8641e6b5cb90f)
jrv = James Van Artsdalen (79ebf81c9d7a5d0f62a5fe9b0a45b3f1f6bf05cb)
jrv = James Van Artsdalen (fcea7c693016ce8fe9ece2eeb40534c9d50c7291)
jrv = James Van Artsdalen (e824d613cb5c41632773cdf1c1fae3a31660e21c)
jrv = James Van Artsdalen (a075b7ed09151300ec290ae3ecba3873ccdf502f)
jrv = James Van Artsdalen (8786aa5d3191ff1a13a3c867c4bf1bd0ba8a4f0d)
jrv = James Van Artsdalen (ebfbe275d63337a1ba433581eec7c021d692cf85)
jrv = James Van Artsdalen (b351a30cae72fc28457e555a463dc03463151886)
jrv = James Van Artsdalen (5fb00bbae2507cdaa3b6307496c9dc4e72a7bf21)
jrv = James Van Artsdalen (b2f37cf4a59d130ad524bacefb509cb13c45ce17)
jrv = James Van Artsdalen (6056a1ef3028e3992da44bf8802ea560a3c14ac3)
jrv = James Van Artsdalen (13f54a5fba352cc69877c55ca1219df0ef5e6e1c)
jrv = James Van Artsdalen (2ba7636ebda06aa454f82160bfc7abab54f46dbc)
jrv = James Van Artsdalen (20b4e8add0380cd81c84bbd9c816fcd6f34d8b8f)
jrv = James Van Artsdalen (c4453285bf72424b6b318f5759ed82e1c8cc722e)
jrv = James Van Artsdalen (32136a4e83863331c0d329b6de5390d06b6097d0)
jrv = James Van Artsdalen (1e702f9a269b2b0785b3bfc699e8f127c1ab43f7)
jrv = James Van Artsdalen (f240fb67cc15120f6276236ed857929aac6364b1)
jrv = James Van Artsdalen (7276ff4dc61bc6d14c977e6616b69922e7df2ede)
jrv = James Van Artsdalen (54bcf6355a4c9fb61fe2e196968a7dbcec98c914)
jrv = James Van Artsdalen (8d3f2cd236318da7cfdf4f175549ce3f322dc48a)
jrv = James Van Artsdalen (2e444e99bf6b08bcf2871fea298a995396cf5f64)
jrv = James Van Artsdalen (122b6c5af8b139f4c879dab0619dcfd79a1fc008)
jrv = James Van Artsdalen (ce794606931481d233ff26ad3e517af46078f5e4)
jrv = James Van Artsdalen (f1b63b839f98fc266c4d5adb6e851c215342bc66)
jrv = James Van Artsdalen (c281cee8db7cebab74d76e04bc13773295a7b31d)
jrv = James Van Artsdalen (6700ed843f553eaee6400d9d7d9f59543ddcb6d6)
jrv = James Van Artsdalen (82f581635ea448e23809eee4e7fc0299b664e23a)
jrv = James Van Artsdalen (d2fa8f02996fc3f299e7a104488b7ec03e187a12)
jrv = James Van Artsdalen (bb686b84134232815a9a853468feba6f09cfe7b2)
jrv = James Van Artsdalen (9d30507e74414763a57df642efd7c8631856eb9e)
jrv = James Van Artsdalen (9e9241b8ad5fdd36347d2ffa67e48b2c63f9e22a)
jrv = James Van Artsdalen (acc5060b542a5a13bce2970a7d40aacff925df0e)
jrv = James Van Artsdalen (0419055bda5b5edfaa61d10e7c734e317930dae5)
jrv = James Van Artsdalen (560d12efa0d480d6246533a926b38024ac539481)
jrv = James Van Artsdalen (4f61287607bbe372a882813ca240ba4142eb3f0e)
jrv = James Van Artsdalen (595d9306b5462163ce9f921ba704c536f3515caf)
jrv = James Van Artsdalen (c88fd083654e36d45a53481089d3d5c239d25069)
jrv = James Van Artsdalen (fe0ea0af32479ee61974182586ef9a83614d00a0)
jrv = James Van Artsdalen (49b1c07f59eb514d4df0cc3bc2edf6c0dfe109e3)
jrv = James Van Artsdalen (a9ba35fbe36d9e488b0a14d07ff67c5c96f8acd0)
jrv = James Van Artsdalen (8fe738b1c55b9a23b754394895034e1bc623b548)
jrv = James Van Artsdalen (f26a4b6193e58c500bad209d9a1500de3d158e40)
jrv = James Van Artsdalen (826f04d9bb4c1d2996eb13dc8d9ad5fbb3415567)
jrv = James Van Artsdalen (607d7b103f15bd9e60f8d169314f00c8c533d51e)
jrv = James Van Artsdalen (086f24274bd7b897d3f5cc1236c8827b6a45a000)
jrv = James Van Artsdalen (07a31354419025128b3594958d540fdf20df2f0f)
jrv = James Van Artsdalen (fd358ca5cb3190f59695f76a050cb57d1c5e67a4)
jrv = James Van Artsdalen (682713f6fc313cba0253325c7e06cdbd371d59af)
jrv = James Van Artsdalen (481b0746103a77d27c670b553a573d84377e4f89)
jrv = James Van Artsdalen (cec64920ac1731485dfe5880300673909452f3c7)
ian = Ian Lance Taylor <ian@airs.com>
jrv = James Van Artsdalen (042aeb40629f38233b627c25b03ed380a3bf67da)
jrv = James Van Artsdalen (99b02dc7876bb494603e5bcfe5353219e390cc59)
jrv = James Van Artsdalen (5e7a3068bb5e6c946f96390268da85ce7ab6c6ab)
jrv = James Van Artsdalen (9a0e8e927a6b51198e7c01f90c311b72e711b47b)
jrv = James Van Artsdalen (f0c8be598fe00c57deea6ee248d0a0d9f0401f5d)
niklas = Niklas Hallqvist (a70b428859665224b6a9e1abb3b17137719b24eb)
niklas = Niklas Hallqvist (64588de133255b17e44cedd6ebd14e5b56ce5d76)
jrv = James Van Artsdalen (a9b6966bd5b63e4f19b07d4d4fd177c8c87a5894)
jrv = James Van Artsdalen (3f89e86cb9d22209109440240905b4674a3b928e)
niklas = Niklas Hallqvist (ceee5ef4821e56976f23af005e8460d1580af790)
niklas = Niklas Hallqvist (c4a77ec85b272253dda5e119121448e83570dcf0)
jrv = James Van Artsdalen (ef3219d45d380373e9f29dd88f20301324d00250)
hassey = John Hassey (5344935f92cde2ea2d58f5f1bc7c585033e15c53)
hassey = John Hassey (2d274acf7884626abe4589d582b00c00e6fe787e)
hassey = John Hassey (12d1c03cb53aaadf98075134d3a8bb9e1caa2e02)
hassey = John Hassey (018317ea0e1cfc9fb489310e2561b0f251cf23d5)
hassey = John Hassey (a4e6e31ede67dfd6d6222954c4b25ef2f9e613ea)
hassey = John Hassey (8532b4460f2151165dce468d1735e256bdfc70b6)
hassey = John Hassey (23902da60c2a7c05661e72977da2bcf93288ee56)
hassey = John Hassey (d2a214720731ed85a5bbef7703704e083121f4eb)
sac = Steve Chamberlain <sac@cygnus.com>
jrv = James Van Artsdalen (9a33656bd26104d7daf5d5fd24b47a7462e8d009)
jrv = James Van Artsdalen (76170098d8943dd1a86fadfec6e450e5e7e9b7f0)
jrv = James Van Artsdalen (8fb78de4ce5e728a83b0a145d16971274577ef8f)
jrv = James Van Artsdalen (2f4ca4403eed58bbd3a053b12bc3b8cb569ec8eb)
jrv = James Van Artsdalen (8236175f10c3bcbf191e404844465d9b1b2333cf)
jrv = James Van Artsdalen (57c96ea598b9f7b24c0b6d2db31e2a422b9e4c36)
jrv = James Van Artsdalen (1616fce53437ad49b2e75d506acae5634f42d5e7)
jrv = James Van Artsdalen (97a9c37d6e2a62d77aaa470c8f03cc2efe244303)
jrv = James Van Artsdalen (89525da0a9fe33ca41457c39da699c25d0d4a39b)
jrv = James Van Artsdalen (3eba6fa066486acb308daaa70d42b1dd16dfa9bb)
jrv = James Van Artsdalen (d6307450847ce84c5abd8bc1cf02e4397178f051)
jrv = James Van Artsdalen (ccd061c42b39fe267861d5d9fb1cbacb245f1733)
jrv = James Van Artsdalen (c2ee31c09ed9226794a47ebf6bd489eaf429f860)
hassey = John Hassey (21974bb92a8e724beeb4dfc0617d2687c934d457)
hassey = John Hassey (17f9985372a4c7e37bd7dddc8610ab4f9c2df13c)
hassey = John Hassey (ad01aca828de71b97633f75f95bb743804fd1bc2)
hassey = John Hassey (4e655e984cd20e9a93c12a959d211e5d2871fe9c)
hassey = John Hassey (96d87fb390f5aac37cf4f18e40debc52dfd4b6d1)
hassey = John Hassey (0250274278b0b5e72c6addc7021458c0e8e7de11)
hassey = John Hassey (578d7039112dc2ceb90f696da441a480a6267840)
hassey = John Hassey (12c062bc6a5804650cbeb7e47655a7e673aca294)
bill = Bill Cox (eb9d9de2921daeea66176c27144bc7d6fcaf6b26)
hassey = John Hassey (311f2fbc98dafedd2ac401a64a9aafef0587b3e2)
hassey = John Hassey (e7c9376d6b7426cc44bfb389f17bc44030f53143)
hassey = John Hassey (4cd502ed9e7a534e5431c099051dec02327bd14b)
hassey = John Hassey (0ae2c7e66d5c30658f2c2577b1a26604556926c3)
hassey = John Hassey (566cea9c536e5c58b0d3854d45080ab8163406d1)
bson = Jan Brittenson (7f4acb6dd6a0bb6a524d51cdd3fb61b84b92ab03)
bson = Jan Brittenson (9175412d6ac92ee9a762d3033177fcbf9359a75e)
bson = Jan Brittenson (649d8da671b8294cfd36bbbecc22d2e6d70f545f)
bson = Jan Brittenson (4b34ab6c26d4c03eca7c62f81257b345c159755b)
bson = Jan Brittenson (9d2d275c3ba780cf57658829daffd420ecf3f871)
bson = Jan Brittenson (852aede467a5e07d5fba5c8d36bde1abac3a5252)
bson = Jan Brittenson (c6b9e095c3e27774d0e47f03d3a9ed2920d968f0)
bson = Jan Brittenson (a91b6667cacc798e314b31237ac54dc7a4524e4d)
bson = Jan Brittenson (c8853b9778e823849ab521d81e2131e7e3e294b6)
bson = Jan Brittenson (fb2e3f7e4f3a95f11b32bf07015606995470d7a1)
bson = Jan Brittenson (41bd1d866685763a862a09bd5cce8faebd9a9a5a)
bson = Jan Brittenson (715cdeeba4399cd5fa1668032582ce05685050e4)
bson = Jan Brittenson (05463d5a45d9c6b32e7b7effd44547e23250a2f1)
bson = Jan Brittenson (8e4c05daaa31b101aaaa4fe9595c3952a2f59dfd)
bson = Jan Brittenson (aff181ad3a45ae14aaae6b5b7e706e37a7334553)
bson = Jan Brittenson (112843241dfacd66e72e950a4bb249facafcde8a)
bson = Jan Brittenson (5106306bef04c0fa0d5f8650e17df8954602e740)
bson = Jan Brittenson (e04a978fc825fe9c79bf573d90780618d07297a5)
bson = Jan Brittenson (319aae7cedee46a43d43a559f337692201e702f6)
bson = Jan Brittenson (852e59cd170122221d1d3852654179b0c3d37e64)
jrv = James Van Artsdalen (c2f3c84e08bc059f574a5d05b32b2f22208ae1c7)
bson = Jan Brittenson (832bfff49082e7b4cafbd74f0bb7b42fbc1e5570)
bson = Jan Brittenson (1e9f9833606b96e14957b8fb9a21a21e00553454)
bson = Jan Brittenson (a1a5a156eec7ee6ea67671dc48467a8d7d9527f7)
bson = Jan Brittenson (aa748ba3dc5184bdfed5edcda7fa47dc42bb011e)
bson = Jan Brittenson (4791e269efe66fcc54094699bb5a92d06ce9ba31)
jrv = James Van Artsdalen (252eb47d848b53e5cd1cd553ff4f869426cd1509)
bson = Jan Brittenson (c24f5795c8fcba8018c56ac7d9a79da17f6b665e)
bson = Jan Brittenson (11841bc460bd47a24cff31a936d3a479f54b88b5)
bson = Jan Brittenson (cbce27c95fb78cb5d6f5a20147bc1f237dea4794)
bson = Jan Brittenson (e78095bc70471a5490122fc3e798fb17f4c3c07a)
bson = Jan Brittenson (19f86bd579769973e387d1319d4f4cb77044561e)
bson = Jan Brittenson (904dc0364ceaca0b053f84b50331b30549252f74)
jrv = James Van Artsdalen (bc3542554d976487f5de614e14060e27ead96006)
erich = Richard Earnshaw <rwe11@cl.cam.ac.uk>
jrv = James Van Artsdalen (7eb486752e14904df57df3dd09a681a68c3674fb)
jrv = James Van Artsdalen (0898f59ef5dc572459a862e371d71744e3309d77)
jrv = James Van Artsdalen (f924af1f50e18568052d07c92a017951d1e65c35)
jrv = James Van Artsdalen (fcf8b28a675f00b4caf8ff545adbfc5c3f7985cf)
jrv = James Van Artsdalen (158aa6c0fc931ee0ecf622265d01b973b8b30a98)
jrv = James Van Artsdalen (062ca0c5a82f53c3130f36cb482431bb0fb78391)
jrv = James Van Artsdalen (32ebc9ce5c7767d69be0e7e9b7b83b0370a0988c)
jrv = James Van Artsdalen (b6e49ac059869ebde9e9a9383837c9dc9b799ed7)
jrv = James Van Artsdalen (ca437bbf509305c058ee0243a9bbb9cf4b9069f2)
jrv = James Van Artsdalen (04442deae498dd549cdc057d8ce60159e9cf13f9)
jrv = James Van Artsdalen (7a6c2a84c8e41d1b75e16beb8ad3925e1c48ecd3)
friedman = Noah Friedman (20881ddcd50ee9d7707fbdef3b96c76855313615)
friedman = Noah Friedman (06d7dfc1eb2894002d14f195384dca994eabc9a5)
hassey = John Hassey (67638b12b2b26d20c081b06a4a2ace04caf403ab)
jrv = James Van Artsdalen (cf03b15bfe4434751445aebd9bc808e4e6848af9)
jrv = James Van Artsdalen (813fb313d930f8f31119d22e3f541c6db39a4cbd)
kenner = Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
coxs = Stan Cox (99f4429fcc63c59b942c85f55c167ecabec71368)
coxs = Stan Cox (b309bd6ec140ae9af115265eb7b956d237aafd6a)
coxs = Stan Cox (c4e8aba227b0b341cc765acbb36752380284fac2)
coxs = Stan Cox (6256a65b9aaf36fa7e1591da846e77419805bb58)
coxs = Stan Cox (96ecd327c06cd9d3ff0a023490f78e79853228b2)
coxs = Stan Cox (bf81e13bcd2889f61150eaf9b13b6ba78aa672ac)
coxs = Stan Cox (3a5390f6ebf2549d9ff5325b06a16b3a2a7807da)
jrv = James Van Artsdalen (0a56d528764211862f7216f9d8b9f3c0ae48541a)
fp = Frederic Pierresteguy (2b2a5facd3108f09ad355ab53e31549b80c035e2)
merrill = Jason Merrill <jason@cygnus.com>
bill = Bill Cox (74c3489ddaca8b746309274f524374e158e19652)
brendan = Brendan Kehoe <brendan@lisa.cygnus.com>
tege = Torbjorn Granlund <tege@cygnus.com>
merrill = Jason Merrill <jason@deneb.cygnus.com>
coxs = Stan Cox (6807ed58b15fe80ebe35621d1768cb42b3e9e366)
coxs = Stan Cox (4952048f807b2ced88eb101729d15a0e1cf6b4d4)
coxs = Stan Cox (d0edcd149a1049b3839ec045f871929048fa0072)
coxs = Stan Cox (c77418c3155c3f6c5e04c2a84b491d3ec452bdc9)
coxs = Stan Cox (6bddd3a6178e94992c20e1264d86aa6aa03dfcdf)
mycroft = Charles Hannum (b81452b1521614ce0453de8c96ff4cc1e2d1a862)
coxs = Stan Cox (26db6c7d536d560a138373286c6f9e0388ae2810)
coxs = Stan Cox (62ab94536ca3aa14510c358e106b749a05c45ae0)
coxs = Stan Cox (1fc0d36d8ce72acedfe23f4992d1f6ecf97602ab)
friedman = Noah Friedman (8fbd3a077f87aba9f1f00d55030f3726c2c2d0c5)
mycroft = Charles Hannum (8eb50f7a305c54acd6790301a0e9555fffd6eddb)
mycroft = Charles Hannum (28762ab555e0c826f3dfa1911b46faa64b826c09)
mycroft = Charles Hannum (1c9c8e5d775886534fa67ea2b9ab984acc8273cb)
mycroft = Charles Hannum (9652ac0286e24fb1424ab2763d1b0fd77e303ba9)
mycroft = Charles Hannum (c5f2aa9211caa6d1a090efa74af578ed60ccee0a)
mycroft = Charles Hannum (8573d66890841eb79dd7dcf2bdb2918866210ec1)
coxs = Stan Cox (7130c3c34c18065cf2ffd5188dfd302eac0865e3)
coxs = Stan Cox (fa4265dd766204cf4a84be200c0aaea66d30e9c8)
coxs = Stan Cox (4fb054daf3e062cf637cd9b8ba4185956271b5b1)
mib = Michael Bushnell (13ea37e5bed8962714bd241fa74242762e94dcbf)
mib = Michael Bushnell (5edb2a85f3cdcee90d045b6df9fefbf82ee1e077)
mib = Michael Bushnell (e8890ab70735d6edfe11abe5d1c38279ea38fd3b)
mycroft = Charles Hannum (93fccc0a874bbbcf274f2904254a1249f8ac919f)
djm = David J. MacKenzie (ad70be9f4db3eb4d355adfa0dd43258d19ca3397)
brendan = Brendan Kehoe <brendan@mole.gnu.ai.mit.edu>
mib = Michael Bushnell (fcf26cc81354be5d0c354fea86fd460ba52e93b5)
mib = Michael Bushnell (643b2c72fd7e65de45e113bec0f5a4ec6f28e5c0)
mib = Michael Bushnell (b6ceb66c406dfc797d54b5758e721c34035bbc1e)
coxs = Stan Cox (01762adde94e10dabce2fec07e0344e77797f775)
merrill = Jason Merrill <jason@phydeaux.cygnus.com>
friedman = Noah Friedman (1a7948a32a275e331b59a0dd3e64efeeca40e53c)
djm = David J. MacKenzie (2a52a86bf127361e5d5fd66e18e1ef44c6d1fc22)
mib = Michael Bushnell (a9d104671619589c3f7954b6ea07b65defb0fe5d)
mrs = Mike Stump <mrs@wombat.gnu.ai.mit.edu>
mrs = Mike Stump <mrs@cygnus.com>
kwzh = Karl Heuer (7f002481b539b4cf9f4e92d20492fafed05b000a)
meissner = Michael Meissner <meissner@cygnus.com>
moshier = Stephen L Moshier (9e08689897ed2a252dc1cade732d9be0cac1b38c)
djm = David J. MacKenzie (e566ed8c7e4b7760ed7c2e3c2e24d2211d229c34)
djm = David J. MacKenzie (96fd04c2a27a7832bd856d553eeff43a1bccc174)
brendan = Brendan Kehoe <brendan@lisa.cygnus.com>
merrill = Jason Merrill <jason@cygnus.com>
coxs = Stan Cox (6f3d4fca53051b305639310191a7478baa87b291)
coxs = Stan Cox (aa6fd500a661cb232afea9a48b95be9ee632d932)
coxs = Stan Cox (31de6b680dd41d0a6a06e8b70eb183b3e7f4a13b)
coxs = Stan Cox (9ba6f64b1f8e9c4ff11ce735e9e85227e645f176)
coxs = Stan Cox (cd06d8652bbc7464eff8527641a8fd7c83064449)
erich = Richard Earnshaw <richard.earnshaw@armltd.co.uk>
eggert = Paul Eggert <eggert@twinsun.com>
coxs = Stan Cox (d5c4eb5c6690281587c32d4fc87f633f68db710b)
law = Jeff Law <law@hurl.cygnus.com>
erich = Richard Earnshaw <rearnsha@armltd.co.uk>
coxs = Stan Cox (91afe2a644820fc3bfb935ff3e9dfc3aec5693e1)
coxs = Stan Cox (4526a1c66311a5217966a7a636aff81c6f15359d)
coxs = Stan Cox (8fad06676fe7da8800ba2a204b0faaabc7ce6f9b)
coxs = Stan Cox (7c81aff1c309141be55a4f3b2c8eff76bb92366b)
coxs = Stan Cox (86e36b8edaf19b701d0bc0554077e946866575b7)
coxs = Stan Cox (ee7fce96779dcd5f27f0202426f42dc06b9d8b95)
coxs = Stan Cox (07240db5771711a6311a5239516e4dfa2484f8b3)
coxs = Stan Cox (33c29f8f4b6daf58d1550d974a6fc5bf4451d5c6)
coxs = Stan Cox (4430793024b6f24f61bc33d9351454f313d03e82)
coxs = Stan Cox (eeed367f20bda55e415ab30deee0c225c0ba3f2a)
coxs = Stan Cox (aa30ffd5811b668f57101afd09b5aa8b4a29b2c1)
coxs = Stan Cox (6c3b6d5caae3615a766312d4365d562dd41cee8b)
coxs = Stan Cox (5fd0c77672559b698a7415f405823d697076dd46)
kwzh = Karl Heuer (b7c41817d34fcb1a2d445190f315b4c98f6df980)
edelsohn = David Edelsohn <edelsohn@npac.syr.edu>
coxs = Stan Cox (adbc3877099daebe8c59f3d4dbe9b7cce31ea5f6)
coxs = Stan Cox (f5eaac103c79732e27b533d3504c0bff175a92cd)
coxs = Stan Cox (9af5c5d1c3a4e93f7ffbac1f0362c4b37a08aabb)
coxs = Stan Cox (a7cec5ff0132c923939a4583a791e3842b0536f4)
coxs = Stan Cox (e9946e7a59650d2aaed27801645bb4249aef0258)
coxs = Stan Cox (9c2a35c73000919c7258b76eb92aab83e38beb5a)
coxs = Stan Cox (14550ecaa89fc51874b0a03b29a86987fd63b3e8)
coxs = Stan Cox (1ea29aae3594bc29d1108c96593e90b863c86d1e)
coxs = Stan Cox (37be4c3fff4af335eac2d0e8926e1f44f0586e6b)
erik = Erik Naggum (f2cd84d92757feb80c40b3bcbcfdea6b6a2d5e2a)
coxs = Stan Cox (e44f65e31d808023949bdf2eda7f7ba387d068f0)
coxs = Stan Cox (5a9e840225da9132e4590d9c38e03f64dc4a5334)
coxs = Stan Cox (727624435fce274135ba31d5edeb41aad7765994)
coxs = Stan Cox (7ae3a63146f78af521163021e061d76826d52f07)
coxs = Stan Cox (dfb4670796a2e76ff8be6d16884345c18fbbbacb)
coxs = Stan Cox (e315aa688d0df971c3dfeb53b4d1ff22f38684c3)
coxs = Stan Cox (67f34fa552a4487fb5c636493cec9f3b72927642)
coxs = Stan Cox (c97fa00c72bda9242e88f7a90e56e59387c8d3df)
merrill = Jason Merrill <jason@yorick.cygnus.com>
coxs = Stan Cox (ab7e9bb372ad2f18f27393b78d4ffb56ecfd6fd9)
coxs = Stan Cox (42c2e1faf2295995e4d08dac8391e46fff5d635c)
coxs = Stan Cox (aa1714512e049f70727e0757a21a5d6ec74e865d)
coxs = Stan Cox (05e63d76abb061a3fa7d0628d209cb0cf2d5ab90)
coxs = Stan Cox (4b708a9ee758738d8c47ff4fa9a5cffce58748a7)
coxs = Stan Cox (1feceddb1d7f00a48ae30ee2108511d93470eaa1)
coxs = Stan Cox (f59e1ed141462f6500403af733367325b543a198)
coxs = Stan Cox (d2b0b90298e4f9d48e09e3a672e84aab31ab1533)
coxs = Stan Cox (084ed8d0cc607665747d2cce4f68e904b74f0922)
coxs = Stan Cox (e5a152e481640ee233d80e929e7e509bc391b014)
coxs = Stan Cox (72ef6797ef79f33416ec9d8c5f79fb5f30e2ca7a)
coxs = Stan Cox (697ba2be0ff3de85dbea0228e6be5a0cb5c6f19a)
coxs = Stan Cox (be60ef7849d2ba4f53d03851865a545fda8c72b6)
coxs = Stan Cox (94babb5d9265677182a40bdf3674613e54aa4f01)
coxs = Stan Cox (ea0f764e6e6fdce0ef97718efa572a32f0a4d5df)
coxs = Stan Cox (32fd8c6afe44030faaeb84c8d3ca7b77dc4ea7d9)
coxs = Stan Cox (5e9588e805aec2ace808a0a42fb3ec1b976269b8)
coxs = Stan Cox (0f412096ec4db29af6268c45dd816f05a36b3206)
kwzh = Karl Heuer (2922f2470963c3698463e18de307bb71bc218a74)
coxs = Stan Cox (8903505fa47d98c7b685a2e32ecb0642d67574a6)
coxs = Stan Cox (802788af7452614d3efcfcd2ea54cd10dca54197)
coxs = Stan Cox (54ed7be011f207c9ad480cd2d578751e52441680)
coxs = Stan Cox (fba058b783150698c1445309f97c6f8d7afe5c2a)
coxs = Stan Cox (9786a867cfcc7df136a07fad906033335c9a8fb6)
coxs = Stan Cox (2aeeeacc0433340410ce3be8c3b136d210b44b19)
coxs = Stan Cox (e31d7821e1df2c2557d7d273909b0c34c77713d0)
kwzh = Karl Heuer (3151d4af0d94d97d3ef1e51ff5fff89e57f44ec3)
kwzh = Karl Heuer (2e00c07b0962caac261b4a4331f965235ec5af4d)
coxs = Stan Cox (ccbf0dd410d2952da6628e6817c116be0d59a843)
coxs = Stan Cox (9cabb0d741fc250094d1b7e21cfbc95e16ac07b0)
coxs = Stan Cox (3b6662db1dfd89b09eb10a2278fc17ef36cca679)
coxs = Stan Cox (b9106545e6669c4fa246decfd932648e96516396)
coxs = Stan Cox (38b4b39c3116ed0efc9008d501346d7d1d561cca)
karl = Karl Berry (488fa66343786ea89e4bb0f3a2eecde40150febe)
karl = Karl Berry (65eed5eeaf64c152d92afd51ecce53dea3a10937)
karl = Karl Berry (7e8abc9e4e0effbc0e4d8f71296a7706dd8ca85f)
karl = Karl Berry (d99e0138af909249db5a158047b19cd0d92d32d7)
coxs = Stan Cox (fee66df7ae2a3eb4b49c2f5665aba5ef841affc5)
coxs = Stan Cox (e0bfa90a4563ce78722e68fb77644694105ff787)
coxs = Stan Cox (7f9556b46de13044ffb24408c9491e6601b3725a)
karl = Karl Berry (428ad2ebd52d3eefd8a1623dc320188697055261)
karl = Karl Berry (2dbf625c9eaae5074a9495c790d7592510f2cb47)
meissner = Michael Meissner <meissner@tiktok.cygnus.com>
coxs = Stan Cox (1b77735c2d937e1420147465212a5c7fe78712bb)
coxs = Stan Cox (247a20826db0c75184d3ef9479b1dd70ea837a2a)
coxs = Stan Cox (5be747c23f75c1400f6fb37767f3f5b44b631932)
coxs = Stan Cox (f5327ccbe4d8463510f439fd29b24dd6455b39bd)
coxs = Stan Cox (fa847262e3af602c1cd5785b237820fe186664b9)
karl = Karl Berry (46f2c838553ecdb455f6170fb84a79bf54f16a34)
coxs = Stan Cox (1d2a453c25c37fe031772240bda932461f04fd68)
coxs = Stan Cox (f13fc0a105815d3c540026bc38b3737d69928991)
coxs = Stan Cox (b845255df0a54d3d7fa4d1ff34164998fb921372)
coxs = Stan Cox (d0d59a93123390f0c363f6c1319f2fc392df33f3)
karl = Karl Berry (1ee2430282a84d8db714c2fcdfd107e72d774315)
karl = Karl Berry (8b87c97c204a0c3b133959672641eb1cfda97835)
ian = Ian Lance Taylor <ian@cygnus.com>
coxs = Stan Cox (fb4ef292908580973c14e140c8a15232c40983d7)
karl = Karl Berry (bddbb00e5e1b826a753534cb8bedafe9841f4a20)
karl = Karl Berry (d4974fe024bf26db401c69b5d42d3b8035a0d937)
coxs = Stan Cox (0d3100df0033fc507c210fbcefee1e90a98f0bbd)
coxs = Stan Cox (968a1ba09ec0c2c2404fd42b02235e136fa85b2e)
coxs = Stan Cox (47d780b2c9e7f112595ea0739b023ab96cf56277)
karl = Karl Berry (37744d377b41a9831388d2ace29770a0a79682af)
karl = Karl Berry (f6bba5f9017ac71e9b7974dceb12219ca9405956)
coxs = Stan Cox (2bc9393a15f8cfe43b39a009a8ca6b9297a9bce4)
coxs = Stan Cox (643ba24c40650fdd8dc7f597cd724b3472be2b3c)
coxs = Stan Cox (d03d26a52b662ac38fb9a07a74413f0912c3a5ae)
coxs = Stan Cox (33c393ebd273ae1208f505ee5b2b871d7ceb36b3)
coxs = Stan Cox (1bf26ca1cc4687efb464734ac1a5459cc18bf3da)
coxs = Stan Cox (8cdf659dd1d404f78effa5e174393995fc8b03c0)
karl = Karl Berry (99eab72295e4c5a578e06e10b8f4a99d61c52a1e)
karl = Karl Berry (5c4ff3f247691e746c733860022e1f51a32c0201)
coxs = Stan Cox (47188603c88f00f01e53107b4ac6b0b390bd132d)
coxs = Stan Cox (cef90107b5c7fbf9abd2c2da1778f644bb34e01b)
coxs = Stan Cox (5de05df815223f70a72a6509f898bea36db7c8c0)
djm = David J. MacKenzie (18e7c018441ea0e7a59aaf89ad979a9772dd25bb)
coxs = Stan Cox (632c6b15f155ee392da8cc0aa84950adaa6a7878)
karl = Karl Berry (f94e12009eae4a7319da8f8cfd6845d7b10f93cf)
karl = Karl Berry (cb52a2a0f5a6111e1bfe283c569b72b29f4c9cbb)
djm = David J. MacKenzie (b715d3a852b8d170e32ede76775422eb9bbaf0f5)
djm = David J. MacKenzie (6dfdcc08176007ac35821622763c6249835c959b)
coxs = Stan Cox (9b000e3e1077b892cc87351b9e7db79e6b6d3206)
karl = Karl Berry (c4c48d8f3989410014af272aad7a924f229cc187)
karl = Karl Berry (76a517036e3229b776fbdeb47d8a0873ac54e1ee)
karl = Karl Berry (3411de0d45847c5a3e9edb4dfbf3fa13ef8707e5)
karl = Karl Berry (04be75f4052c4ad6ffeb0afc8e31f7fa9a04dea5)
coxs = Stan Cox (370c6b99ce73fa7dafa5ef6e3806786369367b8d)
djm = David J. MacKenzie (50ae227ce49646929f201c2a5b5eb199a675a568)
thomas = Thomas Bushnell, n/BSG <thomas@gnu.ai.mit.edu>
coxs = Stan Cox (ecc692ef9f20edf050443b1b420814e2a910f552)
coxs = Stan Cox (1ae4569e70ac01cd2ac48d59007f1ca5ac6f0c74)
djm = David J. MacKenzie (30e02eb76f87115a5abdb605a0f672cbecc48ae5)
law = Jeff Law <law@cygnus.com>
merrill = Jason Merrill <jason@cygnus.com>
coxs = Stan Cox (d8992b5c2c6bd18c5d1b96b5446300ea8d5d41bd)
coxs = Stan Cox (5db3af13b55055c7a774d2ec50265477b9fef50f)
drepper = Ulrich Drepper <drepper@gnu.ai.mit.edu>
karl = Karl Berry (f4d50e184d66435f980127decb58372c95eea4f3)
miles = Miles Bader (98c5c746858fb170edd2028b5863344c69a347ca)
djm = David J. MacKenzie (effb482ad92364b905969439f5c6528eaf0f0b00)
coxs = Stan Cox (dc55f48c06c8fa7d1a5770229d368697b5531c39)
coxs = Stan Cox (9eba312595983ea09d3422a0b0c8e2160bd06c1d)
coxs = Stan Cox (7a77b7e0833b7c70f1a4f408bbf88c34a4b8133d)
coxs = Stan Cox (2969de6be252acbcea2a27f178388d471b0b2dbe)
coxs = Stan Cox (26ee68ddd660b0f5276a37d548169295b2f2b163)
coxs = Stan Cox (7e3c99219a729695d88fa8bd306e03886b5b2bf2)
brendan = Brendan Kehoe <brendan@cygnus.com>
coxs = Stan Cox (4d60def296b2982f099620244bcab2a41baa5d00)
coxs = Stan Cox (4b4f2d904c5324413ea385092e2e7addd1c75ae5)
coxs = Stan Cox (459b14245a0a3489a5a5b108a5dbb15738d4d527)
coxs = Stan Cox (399fcf3b81526f67477e2bc4f74f19ba2a514e93)
coxs = Stan Cox (1bca17201ba735efbcd47dcbca2b464ccc686b4a)
coxs = Stan Cox (c6fecfa75c4ca3558cb0a173d64d20ea2859c5d5)
coxs = Stan Cox (a57a8a647ff8d69445bedb913bdbab0079a569ff)
coxs = Stan Cox (dd92cb67e83695c188ccd81daea8f9c413ba1347)
coxs = Stan Cox (5b21db157631e1996dc33604dc5eb6e56b0132bc)
coxs = Stan Cox (9363800b77a7373481aa0e7e05ee6275bc4d847d)
karl = Karl Berry (4bda2e15d729021b20ce94a5b1d33977e6adbc79)
karl = Karl Berry (02ecadc043981c2369193b9d345ce0c9402f2bce)
coxs = Stan Cox (622097e33c0faa938f88c3c3d05fb2d8aa2c4d60)
karl = Karl Berry (6055ceb37ffcf6b650a32ec8ba18a4a128da071c)
karl = Karl Berry (dac287c984d12d237b807ba17ef9a6693a6dcb8c)
karl = Karl Berry (17ac56a4c95e226637e8a6dfca0158fc84c9b15d)
coxs = Stan Cox (5d237b8019a037ee9f40ee1e428d5ff8cc09c0d4)
coxs = Stan Cox (5f53ff905ec20562389bfa3f51afd52d94013ff5)
coxs = Stan Cox (42c689f63d7a188c74dd815037bf9d2cd171cf27)
karl = Karl Berry (97906c21abfa1666acb2fdc5106483d525b70cde)
karl = Karl Berry (1edb809801bc96e83d6b4090ce2ea5cc625a9589)
karl = Karl Berry (d4ab524994fd1e93a3e08778e45584eb43065984)
coxs = Stan Cox (82280733cf15fa787aa6b87aff533fbdc19fa40a)
karl = Karl Berry (4fad039ed3f81f99c3c16a7ac6a7f10551c0cedb)
miles = Miles Bader (9702dc86e70add11fcda60e34570f5005827951b)
karl = Karl Berry (941a5fc9ac80cb780fb565a7f62b6927bcf5105b)
karl = Karl Berry (3f5670fcbf325fb16a86a462ffe2f31cde296e65)
karl = Karl Berry (058c59ac46fd135c75fa604606de0b5a31bf49a1)
karl = Karl Berry (408f00650d86e0e6a79855af57972bbe1a648180)
karl = Karl Berry (f6acf4de87af24593968bf69ed1c7b5873d299e6)
karl = Karl Berry (ec786181781df1caec83c67604b9d98866169fdc)
karl = Karl Berry (628d861ca3954ae5e4a263fec94a69ef65645bbf)
brendan = Brendan Kehoe <brendan@lisa.cygnus.com>
karl = Karl Berry (db91381011d5f86da6e820144d8491f3d790d9a5)
coxs = Stan Cox (16f8acc9d9dfcb2c8b528739e0531a6d39b7ee17)
coxs = Stan Cox (58939df20cb5b3026971564dae1e1de213f429e2)
coxs = Stan Cox (1cc9ef69f233ff5c69afeb6d1ef7ef907f8fa1af)
coxs = Stan Cox (89f5e3db44f7202651432ce334870736b7e17958)
law = Jeff Law <law@hurl.cygnus.com>
meissner = Michael Meissner <meissner@cygnus.com>
jason = Jason Merrill <jason@yorick.cygnus.com>
law = Jeff Law <law@cygnus.com>
jason = Jason Merrill <jason@cygnus.com>
jason = Jason Merrill <jason@yorick.cygnus.com>
brendan = Brendan Kehoe <brendan@cygnus.com>
manfred = Manfred Hollstein <manfred@s-direktnet.de>
drepper = Ulrich Drepper <drepper@cygnus.com>
brendan = Brendan Kehoe <brendan@lisa.cygnus.com>
brendan = Brendan Kehoe <brendan@lasher.cygnus.com>
brendan = Brendan Kehoe <brendan@lisa.cygnus.com>
bkoz = Benjamin Kosnik <bkoz@rhino.cygnus.com>
rth = Richard Henderson <rth@cygnus.com>
devans = Doug Evans <dje@canuck.cygnus.com>
devans = Doug Evans <devans@canuck.cygnus.com>
brendan = Brendan Kehoe <brendan@cygnus.com>
amylaar = Joern Rennecke <amylaar@cygnus.com>
brendan = Brendan Kehoe <brendan@lisa.cygnus.com>
jason = Jason Merrill <jason@lasher.cygnus.com>
jason = Jason Merrill <jason@yorick.cygnus.com>
law = Jeff Law <law@hurl.cygnus.com>
green = Anthony Green <green@cygnus.com>
billm = Bill Moyer <billm@cygnus.com>
law = Jeff Law <law@cygnus.com>
brendan = Brendan Kehoe <brendan@cygnus.com>
davem = David S. Miller <davem@dm.cobaltmicro.com>
jfc = John Carr <jfc@mit.edu>
amacleod = Andrew Macleod <amacleod@cygnus.com>
mmitchell = Mark Mitchell <mmitchell@usa.net>
robertl = Robert Lipe <robertl@dgii.com>
rearnsha = Richard Earnshaw <rearnsha@arm.com>
manfred = Manfred Hollstein <Manfred.Hollstein@ks.sel.alcatel.de>
fx = Dave Love <d.love@dl.ac.uk>
manfred = Manfred Hollstein <manfred@s-direktnet.de>
schwab = Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>
raeburn = Ken Raeburn <raeburn@cygnus.com>
ghazi = Kaveh Ghazi <ghazi@caip.rutgers.edu>
nickc = Nick Clifton <nickc@cygnus.com>
mmitchel = Mark Mitchell <mmitchell@usa.net>
korbb = Bruce Korb <korbb@datadesign.com>
scox = Stan Cox <scox@equinox.cygnus.com>
bkoz = Benjamin Kosnik <bkoz@lisa.cygnus.com>
scox = Stan Cox <scox@cygnus.com>
bkoz = Benjamin Kosnik <bkoz@loony.cygnus.com>
brolley = Dave Brolley <brolley@cygnus.com>
bkoz = Benjamin Kosnik <bkoz@rhino.cygnus.com>
mmitchel = Mark Mitchell <mark@markmitchell.com>
bkoz = Benjamin Kosnik <bkoz@loony.cygnus.com>
clm = Catherine Moore <clm@cygnus.com>
bkoz = Benjamin Kosnik <bkoz@elmo.cygnus.com>
devans = Doug Evans <devans@egcs.cygnus.com>
davem = David S. Miller <davem@pierdol.cobaltmicro.com>
oliva = Alexandre Oliva <oliva@dcc.unicamp.br>
bkoz = Benjamin Kosnik <bkoz@lisa.cygnus.com>
bkoz = Benjamin Kosnik <bkoz@bliss.nabi.net>
loewis = Martin v. Löwis (5df5caac37f983f1c1786858d0e30a68f345b006)
loewis = Martin v. Löwis (0261c7fd97e7747016929eff806e3bb581c19b8b)
loewis = Martin v. Löwis (9eaeb753e02c10c494f751fc235dc573e64a45d3)
loewis = Martin v. Löwis (899364bc8409b5f47427830bb77d30279b26f02b)
loewis = Martin v. Löwis (fdac6ae8c28037e6b3836640232d36cc3c411d87)
davem = David S. Miller <davem@dm.cobaltmicro.com>
loewis = Martin v. Löwis (34bc9479807e7875811fcef97eba2fb43380367a)
loewis = Martin v. Löwis (d7d8b1b5a41434e1d57f3cc3e22517baf0af9478)
loewis = Martin v. Löwis (16e8913ad3e8bb6793673c8a9ff89c7e4fd1c025)
loewis = Martin v. Löwis (e443498065965063a7ca3d7fe0c04b95226cb752)
loewis = Martin v. Löwis (9c393d679ebf4f37144d2168b9331fc58cbd54d6)
loewis = Martin v. Löwis (197586bd3f208eb9622b3988df85f3df5183384d)
pcg = Marc Lehmann <pcg@goof.com>
davem = David S. Miller <davem@pierdol.cobaltmicro.com>
devans = Doug Evans <devans@canuck.cygnus.com>
gerald = Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
gavin = Gavin Romig-Koch <gavin@cygnus.com>
bkoz = Benjamin Kosnik <bkoz@loony.cygnus.com>
loewis = Martin v. Löwis (3eec3eeca717ba1039cf81b562787ab705263d57)
bkoz = Benjamin Kosnik <bkoz@cygnus.com>
loewis = Martin v. Löwis (62992cb88f125642991577882619ca8bca32acdb)
tromey = Tom Tromey <tromey@cygnus.com>
bothner = Per Bothner <bothner@deneb.cygnus.com>
bothner = Per Bothner <bothner@cygnus.com>
loewis = Martin v. Löwis (b70d37fc5a8a89d51f2fe97bc907b55bc0c4bb33)
bkoz = Benjamin Kosnik <bkoz@loony.cygnus.com>
bkoz = Benjamin Kosnik <bkoz@rhino.cygnus.com>
bkoz = Benjamin Kosnik <bkoz@cygnus.com>
korbb = Bruce Korb <korb@datadesign.com>
loewis = Martin v. Löwis (c74b6bda631639b3a39026fb8ffc9d366f03664f)
bje = Ben Elliston <bje@cygnus.com>
loewis = Martin v. Löwis (cc2dea353c267fffce346c7f02c91895f97ad8c8)
loewis = Martin v. Löwis (7dc3584f7138598c287b0ae8ddb36c36cc94a3df)
bkoz = Benjamin Kosnik <bkoz@loony.cygnus.com>
loewis = Martin v. Löwis (03abd7311f5f8649336a106ecb0a55472a885b98)
loewis = Martin v. Löwis (5be0affa1275a3a5971be7dde1cdcfee26adb6a2)
ovidiu = Ovidiu Predescu <ovidiu@cup.hp.com>
m.hayes = Michael Hayes <m.hayes@elec.canterbury.ac.nz>
fx = Dave Love <fx@gnu.org>
apbianco = Alexandre Petit-Bianco <apbianco@cygnus.com>
bkoz = Benjamin Kosnik <bkoz@rhino.cygnus.com>
davem = David S. Miller <davem@pierdol.cobaltnet.com>
ovidiu = Ovidiu Predescu <ovidiu@slip.net>
loewis = Martin v. Löwis (cbf0a8cc232ac278a84e97a2e3cf0e9bbce37f93)
fx = Dave Love <d.love@dl.ac.uk>
loewis = Martin v. Löwis (7bceae648d1126ac05a1e3ec8693d552b7a2636b)
loewis = Martin v. Löwis (7b8220fe7d19aab6ad4c274fc80f8acaf4839148)
loewis = Martin v. Löwis (a9da0873a87df56bbff749dd9da8a1f6dd92527d)
loewis = Martin v. Löwis (e2c842d8a854a16348c124f65c842b4a52cac76e)
loewis = Martin v. Löwis (9f34e895344057e2b05fc61982e118955e9821cd)
loewis = Martin v. Löwis (e56b75e1e1e2517b5b65659750721b733e026f3c)
loewis = Martin v. Löwis (27970e758e8580776afdcb7c85e47db6a0dcd987)
loewis = Martin v. Löwis (d65ef0b1c3bd44c25bf33accbea5dbaf9481553d)
schwab = Andreas Schwab <schwab@issan.cs.uni-dortmund.de>
davem = David S. Miller <davem@pierdol.cobaltmicro.com>
loewis = Martin v. Löwis (a8b439e1eeab0b07cd487e27700bf2592bf4b4c8)
loewis = Martin v. Löwis (4e8042b1cbe021c729e7b6ccf3cb3239285d6120)
green = Anthony Green <green@hoser.cygnus.com>
loewis = Martin v. Löwis (dc1fa59799b2292c14d52273b59225ddc11a5124)
loewis = Martin v. Löwis (7e2edc7a868872185ef42f7a966aa7612b9e1b45)
crux = Bernd Schmidt <crux@pool.informatik.rwth-aachen.de>
bkoz = Benjamin Kosnik <bkoz@cygnus.com>
bkoz = Benjamin Kosnik <bkoz@haight.constant.com>
apbianco = Alexandre Petit-Bianco <apbianco@sendai.cygnus.com>
robertl = Robert Lipe <robertlipe@usa.net>
aph = Andrew Haley <aph@viagra.cygnus.co.uk>
apbianco = Alexandre Petit-Bianco <apbianco@cygnus.com>
aph = Andrew Haley <aph@cygnus.com>
fx = Dave Love <fx@gnu.org>
zack = Zack Weinberg <zack@rabi.columbia.edu>
loewis = Martin v. Löwis (42085533d4ca0427daa8b777dce38e75613dac9b)
loewis = Martin v. Löwis (72800af877e4e1d5033cf4882c7707d482826021)
loewis = Martin v. Löwis (d486ccb8bb636863293f2fde14eca92be382893d)
zack = Zack Weinberg <zack@midnite.ec.rhno.columbia.edu>
zack = Zack Weinberg <zack@rabi.columbia.edu>
burley = Craig Burley <craig@jcb-sc.com>
zack = Zack Weinberg <zack@rabi.phys.columbia.edu>
zack = Zack Weinberg <zack@rabi.columbia.edu>
bkoz = Benjamin Kosnik <bkoz@loony.cygnus.com>
jason = Jason Merrill <jason@cygnus.com>
jason = Jason Merrill <jason@yorick.cygnus.com>
zack = Zack Weinberg <zack@midnite.ec.rhno.columbia.edu>
zack = Zack Weinberg <zack@rabi.columbia.edu>
zack = Zack Weinberg <zack@midnite.ec.rhno.columbia.edu>
zack = Zack Weinberg <zack@rabi.columbia.edu>
ovidiu = Ovidiu Predescu <ovidiu@cup.hp.com>
loewis = Martin v. Löwis (22e2b0d04b4f635c1091942c78f8b6c7079b1db9)
loewis = Martin v. Löwis (331b31783160819bfbabb0496e80deef250b806a)
loewis = Martin v. Löwis (d0bd01f1bd157238046ce138f513077ea241bcf5)
loewis = Martin v. Löwis (47b6b44afc3d9c53b01715905c4b248fcd7fb2c1)
bothner = Per Bothner <bothner@deneb.cygnus.com>
loewis = Martin v. Löwis (d498b23758bfab62301ae80fd8aa38655f1ed3ba)
loewis = Martin v. Löwis (8d538d8afbb9f3eef902c5564f2b81a8a4039632)
burley = Craig Burley <burley@gnu.org>
burley = Craig Burley <craig@jcb-sc.com>
loewis = Martin v. Löwis (c06c53ff30bfd5cffb4f6d490c330de0d475c8d8)
loewis = Martin v. Löwis (43948df8dcecf34eadc74ac7e60cffb6840421c2)
jason = Jason Merrill <jason@cygnus.com>
jason = Jason Merrill <jason@yorick.cygnus.com>
loewis = Martin v. Löwis (358afcdb1a987b7068454c0546e40bdff55b8a3a)
bothner = Per Bothner <bothner@cygnus.com>
loewis = Martin v. Löwis (83ca5d39a56eaaa3d7dad8cbbc04edba6dd3f21c)
loewis = Martin v. Löwis (c820c3d149748003559da20a37c5ce3fd9a76e6e)
loewis = Martin v. Löwis (9c0b3eb9ea96f0a14f8206ccc61c3edb91fda72a)
loewis = Martin v. Löwis (71094e5a89da4c9dcc1cf4b55ffb44dd9f48a559)
loewis = Martin v. Löwis (308c6c5167eb102078750d33df6df625a2bcd339)
loewis = Martin v. Löwis (67b61957b53097c458e720e7f5b9144953b4dafa)
loewis = Martin v. Löwis (d180d0914b13d99c9d2dd73c989f479ce3707efd)
davem = David S. Miller <davem@redhat.com>
mmitchel = Mark Mitchell <mark@codesourcery.com>
loewis = Martin v. Löwis (32b3a273d7fbeeff07cccc6f6346aa71675abba7)
vmakarov = Vladimir Makarov <vmakarov@tofu.to.cygnus.com>
loewis = Martin v. Löwis (29ab538c18ed6589fb2f567bc1611ccb7a574650)
loewis = Martin v. Löwis (46bcd3ae1b3aa32b745ad37763e9af25c7574974)
mrs = Mike Stump <mrs@wrs.com>
loewis = Martin v. Löwis (5fb63f3bac75b1789962145ce3c0526c23ff78f2)
loewis = Martin v. Löwis (c4c8d697fde4083d26c393fd668cba66892ed1cf)
wehle = John Wehle <john@feith.com>
loewis = Martin v. Löwis (4e1479ecb6ab4f6d3ccc3221966970274467c3f9)
jason = Jason Merrill <jason@cygnus.com>
jason = Jason Merrill <jason@yorick.cygnus.com>
jason = Jason Merrill <jason@cygnus.com>
jason = Jason Merrill <jason@yorick.cygnus.com>
korbb = Bruce Korb <fixincludes@autogen.freeservers.com>
korbb = Bruce Korb <korb@datadesign.com>
jason = Jason Merrill <jason@cygnus.com>
jason = Jason Merrill <jason@yorick.cygnus.com>
loewis = Martin v. Löwis (36d897f3d51cd053b81da671eeb12f92259f6e59)
korbb = Bruce Korb <ddsinc09@ix.netcom.com>
loewis = Martin v. Löwis (cf90626caec50fc7fc8fbe793c95a664ae482750)
loewis = Martin v. Löwis (84bbcdff944b9955a1dbaee21abca6dab0070daf)
warrenl = Warren Levy <warrenl@cygnus.com>
manfred = Manfred Hollstein <manfred.h@gmx.net>
jason = Jason Merrill <jason@cygnus.com>
jason = Jason Merrill <jason@yorick.cygnus.com>
jimb = Jim Blandy <jimb@zwingli.cygnus.com>
jason = Jason Merrill <jason@cygnus.com>
jason = Jason Merrill <jason@yorick.cygnus.com>
jason = Jason Merrill <jason@cygnus.com>
loewis = Martin v. Löwis (e5b236105943540d88161f10c71afd2bc128381f)
loewis = Martin v. Löwis (bf41b831d6c5500d19dd76dae949d80604fefdd4)
jason = Jason Merrill <jason@yorick.cygnus.com>
jason = Jason Merrill <jason@cygnus.com>
jason = Jason Merrill <jason@yorick.cygnus.com>
green = Anthony Green <green@cygnus.com>
jason = Jason Merrill <jason@cygnus.com>
nathan = Nathan Sidwell <nathan@acm.org>
jason = Jason Merrill <jason@yorick.cygnus.com>
loewis = Martin v. Löwis (778bd7b0a63375d013dbf7359fde9af99bbd1c43)
loewis = Martin v. Löwis (d133959864dc563206de476188ed476e04be7a37)
loewis = Martin v. Löwis (67160f6c97604c6b1b5b550659862d9f93b7d4fe)
loewis = Martin v. Löwis (7dbdc73ebff50c14483971e7e9095b7120809dcb)
loewis = Martin v. Löwis (b5884f105f38d87e1878d80b15cbdbe3df6ccb50)
loewis = Martin v. Löwis (82904609d6e51cb53b537d54735d299e6cc9ddc7)
jason = Jason Merrill <jason@cygnus.com>
korbb = Bruce Korb <autogen@autogen.freeservers.com>
jason = Jason Merrill <jason@yorick.cygnus.com>
korbb = Bruce Korb <ddsinc09@ix.netcom.com>
gdr = Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr>
bryce = Bryce McKinlay <bryce@albatross.co.nz>
loewis = Martin v. Löwis (83cf81a00c83bea75918497c050fab356b606e9d)
loewis = Martin v. Löwis (8f958b776ee6b21fe1efe290885c9ddd7983c04a)
dlindsay = Don Lindsay <dlindsay@cygnus.com>
loewis = Martin v. Löwis (4608a99fd45d336b8fdd10d66b8d0de6252bf280)
manfred = Manfred Hollstein <mhollstein@cygnus.com>
crux = Bernd Schmidt <bernds@cygnus.co.uk>
jason = Jason Merrill <jason@cygnus.com>
jason = Jason Merrill <jason@yorick.cygnus.com>
geoffk = Geoffrey Keating <geoffk@ozemail.com.au>
zack = Zack Weinberg <zack@bitmover.com>
jason = Jason Merrill <jason@cygnus.com>
jason = Jason Merrill <jason@yorick.cygnus.com>
vmakarov = Vladimir Makarov <vmakarov@toad.to.cygnus.com>
jason = Jason Merrill <jason@cygnus.com>
vmakarov = Vladimir Makarov <vmakarov@loony.cygnus.com>
jason = Jason Merrill <jason@yorick.cygnus.com>
jason = Jason Merrill <jason@cygnus.com>
jason = Jason Merrill <jason@yorick.cygnus.com>
korbb = Bruce Korb <autogen@linuxbox.com>
loewis = Martin v. Löwis (ef10f844e44cc6c0b026d628089d112d7f67abb4)
loewis = Martin v. Löwis (e49f704dc9cae5e977a7deb74abccf2476a4eb0e)
loewis = Martin v. Löwis (32b743ed4e4aa7c246d3cfebefec53e46c67aa6d)
loewis = Martin v. Löwis (d9b7c1cdfd1e257145d91727096935ac5489cac1)
loewis = Martin v. Löwis (5045c2ee46041cf3e19a45ef6efcd804869d8c08)
loewis = Martin v. Löwis (301d4a43024d05c8406ba8734ca6d399b5348806)
loewis = Martin v. Löwis (98239e512c2da8435ade1f5333e8f3c885f4879b)
schwab = Andreas Schwab <schwab@suse.de>
loewis = Martin v. Löwis (d313cacfb310776ad22a864fb852600eb152a518)
loewis = Martin v. Löwis (a0d9dde405c2c3b312369be7899eb7bde5bf9314)
geoffk = Geoffrey Keating <geoffk@cygnus.com>
krab = Kresten Krab Thorup <krab@gnu.org>
jason = Jason Merrill <jason@cygnus.com>
jason = Jason Merrill <jason@yorick.cygnus.com>
krab = Kresten Krab Thorup <krab@samam.daimi.au.dk>
jason = Jason Merrill <jason@cygnus.com>
burley = Craig Burley <burley@gnu.ai.mit.edu>
jason = Jason Merrill <jason@yorick.cygnus.com>
krab = Kresten Krab Thorup <krab@gnu.org>
kenner = Richard Kenner <kenner@nyu.ede>
kenner = Richard Kenner <kenner@nyu.edu>
burley = Craig Burley <craig@jcb-sc.com>
oliva = Alexandre Oliva <oliva@lsd.ic.unicamp.br>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
gdr = Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr>
jason = Jason Merrill <jason@cygnus.com>
loewis = Martin v. Löwis (251b4a90a74fb3b0ea014db0940d1539a118e936)
loewis = Martin v. Löwis (6095d882c004eada91ab4e8238a5d10d2e695649)
samuel = Alex Samuel <samuel@codesourcery.com>
loewis = Martin v. Löwis (da76ffefae325a056c0125ae4cbc61dab7f32021)
loewis = Martin v. Löwis (96149f2d49006c580aa97b97435c0d38d60ab438)
loewis = Martin v. Löwis (788bd876f43a4693ebbdb20f0b463f88e96a0e1e)
loewis = Martin v. Löwis (75a5bb9a86fbc706b6da47805f0c843369982a7a)
jason = Jason Merrill <jason@yorick.cygnus.com>
loewis = Martin v. Löwis (c0919f6484c9ca962576bb205ec0aede7b0c572d)
loewis = Martin v. Löwis (d0d0136917404dbf3c8b52f5d0b6ef5870eaf4fb)
loewis = Martin v. Löwis (ad46fc6a7da5f562b7d8b37cc27c138f87081cfc)
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
jason = Jason Merrill <jason@cygnus.com>
jason = Jason Merrill <jason@yorick.cygnus.com>
dnovillo = Diego Novillo <dnovillo@cygnus.com>
loewis = Martin v. Löwis (c3b441462dce6e12aad897c236b9df0839323151)
loewis = Martin v. Löwis (58ffe168d6b4034557ac947b1a5d9e2c9443ed4d)
gkm = Greg McGary <gkm@gnu.org>
jason = Jason Merrill <jason@cygnus.com>
loewis = Martin v. Löwis (b082e8afb2e3d35269c77d8e98627cfa4b2cfb12)
jason = Jason Merrill <jason@yorick.cygnus.com>
gdr = Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr>
jle = Jason Eckhardt <jle@cygnus.com>
ian = Ian Lance Taylor <ian@zembu.com>
kenner = Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
loewis = Martin v. Löwis (2cafdfc9639416869b9cae510a14878abc20a641)
loewis = Martin v. Löwis (e96e57d538984d7c85064447e10583a9917898f5)
loewis = Martin v. Löwis (96e5d0ea9144258ef4a4548acb594891506284d3)
green = Anthony Green <green@trip.cygnus.com>
cpopetz = Clinton Popetz <cpopetz@cygnus.com>
mrs = Mike Stump <mrs@windriver.com>
vmakarov = Vladimir Makarov <vmakarov@tofu.to.cygnus.com>
jason = Jason Merrill <jason@casey.cygnus.com>
hubicka = Jan Hubicka <hubicka@freesoft.cz>
jason = Jason Merrill <jason@yorick.cygnus.com>
green = Anthony Green <green@cygnus.com>
jason = Jason Merrill <jason@casey.cygnus.com>
loewis = Martin v. Löwis (66694f6f696500d6cc49bba8f8fc6c9233c523b8)
robertl = Robert Lipe <robertl@cygnus.com>
jsm = Jason Molenda <jsm@bugshack.cygnus.com>
mrs = Mike Stump <mrs@wrs.com>
loewis = Martin v. Löwis (a1fccfde31efb53ea995cb6cc1692e156112c37d)
gavin = Gavin Romig-Koch <gavin@cetus.cygnus.com>
khan = Mumit Khan <khan@xraylith.wisc.edu>
jakub = Jakub Jelinek <jakub@redhat.com>
loewis = Martin v. Löwis (a55073df9f73d728cf69d74ca8fcf3fe99c8589d)
loewis = Martin v. Löwis (8cc494fc0a9eeb5d4942bf2a242391cc905af5ab)
loewis = Martin v. Löwis (87ac605e9185c66aea8d32506e65baeb9c26e82a)
jason = Jason Merrill <jason@yorick.cygnus.com>
jason = Jason Merrill <jason@casey.cygnus.com>
hubicka = Jan Hubicka <hubicka@freesoftr.cz>
zack = Zack Weinberg <zack@rabi.columbia.edu>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
zack = Zack Weinberg <zack@wolery.cumb.org>
sirl = Franz Sirl <franz.sirl-kernel@lauterbach.com>
loewis = Martin v. Löwis (96d5dc4b886d53c8aa92c22bf22c8ebce69d1d39)
loewis = Martin v. Löwis (abf55b3bc04946c5d6ef4d1d5187efb65ecdd6a4)
loewis = Martin v. Löwis (94bbf7dc3ffaf29843ed2c2e087ca74a2bf0f9e6)
loewis = Martin v. Löwis (9c94a143b72f591ee03f15f9f265b8585be14524)
hp = Hans-Peter Nilsson <hp@bitrange.com>
loewis = Martin v. Löwis (6b91846292b84d412cf79b48f5708052e317d788)
loewis = Martin v. Löwis (8d2064902baa1cbb012c3a052ad5c7c6bb0946fb)
loewis = Martin v. Löwis (794f5d2dd18ab46b107561defc71258c0fc9c9d9)
gdr = Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr>
loewis = Martin v. Löwis (418a2bbe9796007cfed5e00f26b757a9dd48d0bc)
loewis = Martin v. Löwis (e199faea9f4ec7a4abbc6654b924713491534def)
loewis = Martin v. Löwis (e2051447a04ca4b4b38dfcb214af57a32373f361)
sirl = Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
hubicka = Jan Hubicka <hubicka@freesoft.cz>
loewis = Martin v. Löwis (ebcb1851c4cabf8bace02d1ee97f13291461be1a)
zack = Zack Weinberg <zack@rabi.columbia.edu>
hubicka = Jan Hubicka <jh@suse.cz>
nathan = Nathan Sidwell <sidwell@codesourcery.com>
hp = Hans-Peter Nilsson <hp@axis.com>
mmitchel = Mark Mitchell <mitchell@dumbledore.codesourcery.com>
mmitchel = Mark Mitchell <mark@codesourcery.com>
zack = Zack Weinberg <zack@wolery.cumb.org>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
robertl = Robert Lipe <robertl@sco.com>
jason = Jason Merrill <jason@yorick.cygnus.com>
gavin = Gavin Romig-Koch <gavin@cygnus.com>
loewis = Martin v. Löwis (e76ab83f26f9e8cbfe00af0447fb031cb2e42677)
loewis = Martin v. Löwis (1424d856a75133aceaadb6bb57f76d7c5f0abd00)
loewis = Martin v. Löwis (ece7cbbe98adbab7dcc40c375d3c7f75cd8a1d52)
hubicka = Jan Hubicka <hubicka@freesoft.cz>
hubicka = Jan Hubicka <jh@suse.cz>
gdr = Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr>
jason = Jason Merrill <jason@casey.cygnus.com>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
jason = Jason Merrill <jason@cygnus.com>
tromey = Tom Tromey <tromey@ferrule.cygnus.com>
nickc = Nick Clifton <nickc@redhat.com>
tromey = Tom Tromey <tromey@cygnus.com>
jason = Jason Merrill <jason@casey.cygnus.com>
loewis = Martin v. Löwis (7c3c5db330bcc8ed8ca34baae636141ce98d5df7)
nathan = Nathan Sidwell <nathan@acm.org>
drepper = Ulrich Drepper <drepper@redhat.com>
green = Anthony Green <green@redhat.com>
nathan = Nathan Sidwell <sidwell@codesourcery.com>
jason = Jason Merrill <jason@yorick.cygnus.com>
jason = Jason Merrill <jason@casey.cygnus.com>
brolley = Dave Brolley <brolley@redhat.com>
cchavva = Chandra Chavva <cchavva@cygnus.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
nathan = Nathan Sidwell <nathan@acm.org>
korbb = Bruce Korb <bkorb@gnu.org>
nickc = Nick Clifton <nickc@cygnus.com>
scottb = Scott Bambrough <scottb@netwinder.org>
green = Anthony Green <green@cygnus.com>
green = Anthony Green <green@redhat.com>
aoliva = Alexandre Oliva <oliva@lsd.ic.unicamp.br>
loewis = Martin v. Löwis (57f194be3f697f6431ed5f46df6a8d994f51da75)
jason = Jason Merrill <jason@cygnus.com>
jason = Jason Merrill <jason@casey.cygnus.com>
green = Anthony Green <green@cygnus.com>
loewis = Martin v. Löwis (69e5b74229dfc99b94ca132d3e2085cfef81a9de)
loewis = Martin v. Löwis (657c76e1a2dfa1c35068b406b39e403c9a2456a5)
nathan = Nathan Sidwell <nathan@codesourcery.com>
loewis = Martin v. Löwis (d0309f395d8eec464cc87134d3896056b6449110)
loewis = Martin v. Löwis (b0f1b1c50827bd366ff10d336df2a41c1f4ac71c)
bothner = Per Bothner <per@bothner.com>
green = Anthony Green <green@redhat.com>
neil = Neil Booth <NeilB@earthling.net>
gavin = Gavin Romig-Koch <gavin@cetus.cygnus.com>
bkoz = Benjamin Kosnik <bkoz@cygnus.com>
gdr = Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
toon = Toon Moene <toon@moene.indiv.nluug.nl>
loewis = Martin v. Löwis (86220f453c768a8deb58678e4010a892011a2cce)
loewis = Martin v. Löwis (57083eaea2952f77c284342a4e318ecd6eb8fade)
loewis = Martin v. Löwis (4a53ef87997433856d33847536c7b994bfc91c3c)
loewis = Martin v. Löwis (b464c9a27e108516acae258ef36526de5ebbe824)
loewis = Martin v. Löwis (9dff436883c0540b3876a03ca275d38daf8e5e0f)
hp = Hans-Peter Nilsson <hp@axis.com>
loewis = Martin v. Löwis (f2d8342774dcc55765530e12f7f6914963b9d1b7)
loewis = Martin v. Löwis (78147e84503de46c41e27d1c461a37fcaf37a25f)
loewis = Martin v. Löwis (9b2a9a1282d4aa527b671b38e6744ffa5fd6341c)
denisc = Denis Chertykov <denisc@overta.ru>
meissner = Michael Meissner <meissner@redhat.com>
mmitchel = Mark Mitchell <mitchell@codesourcery.com>
mmitchel = Mark Mitchell <mark@codesourcery.com>
apbianco = Alexandre Petit-Bianco <apbianco@dcygnus.com>
apbianco = Alexandre Petit-Bianco <apbianco@cygnus.com>
loewis = Martin v. Löwis (4a3c722842a1f2aa63cf41e9121a35a968e70337)
drepper = Ulrich Drepper <drepper@cygnus.com>
phdm = Philippe De Muyter <phdm@macqel.be>
jason = Jason Merrill <jason@yorick.cygnus.com>
jason = Jason Merrill <jason@casey.cygnus.com>
green = Anthony Green <green@cygnus.com>
loewis = Martin v. Löwis (7da5bc470c35e37f668bdc42471763d76981ac9c)
loewis = Martin v. Löwis (7b8a297dba0c6203c019a0df317040e9e558f650)
loewis = Martin v. Löwis (1886e87de6421bee912b8f1d37f76339f2d6624c)
loewis = Martin v. Löwis (9065d17ce9ef11af2bced1216da19491909df9ac)
loewis = Martin v. Löwis (e4f7cfabd92c56624ca686c6b68f0889a2586515)
mmitchel = Mark Mitchell <mitchell@codesourcery.com>
mmitchel = Mark Mitchell <mark@codesourcery.com>
aj = Andreas Jaeger <aj@suse.de>
rearnsha = Richard Earnshaw <rearnsah@arm.com>
drepper = Ulrich Drepper <drepper@redhat.com>
green = Anthony Green <green@redhat.com>
robertl = Robert Lipe <robertlipe@usa.net>
jimb = Jim Blandy <jimb@redhat.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
aoliva = Alexandre Oliva <aoliva@cygnus.com>
green = Anthony Green <green@cygnus.com>
bkoz = Benjamin Kosnik <bkoz@cygnus.com>
loewis = Martin v. Löwis (c882f919e9a1378f97cea07d331db46e7d065d42)
loewis = Martin v. Löwis (0e540732f3cf31b162879b5db86abbc5683ae0ef)
nickc = Nick Clifton <nickc@redhat.com>
loewis = Martin v. Löwis (faa4e1f1adb9b6e9be1f7779c322173def604225)
loewis = Martin v. Löwis (33cb84b9ce1269581315acce3c3f1ded4cd12425)
bkoz = Benjamin Kosnik <bkoz@gnu.org>
aoliva = Alexandre Oliva <oliva@lsd.ic.unicamp.br>
nickc = Nick Clifton <nickc@cygnus.com>
aoliva = Alexandre Oliva <aoliva@cygnus.com>
drepper = Ulrich Drepper <drepper@cygnus.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
pme = Phil Edwards <pme@sourceware.cygnus.com>
rth = Richard Henderson <rth@tamu.edu>
rth = Richard Henderson <rth@cygnus.com>
bkoz = Benjamin Kosnik <bkoz@gnu.org>
loewis = Martin v. Löwis (fc188cd061f8d07e4acaccaf9848c315e0d80a9e)
bkoz = Benjamin Kosnik <bkoz@haight.constant.com>
bkoz = Benjamin Kosnik <bkoz@cygnus.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
rearnsha = Richard Earnshaw <reanrsha@arm.com>
bkoz = Benjamin Kosnik <bkoz@cygnus.com>
bkoz = Benjamin Kosnik <bkoz@gnu.org>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
nickc = Nick Clifton <nickc@redhat.com>
nickc = Nick Clifton <nickc@cygnus.com>
cagney = Andrew Cagney <cagney@b1.cygnus.com>
bkoz = Benjamin Kosnik <bkoz@cygnus.com>
loewis = Martin v. Löwis (53ee71bc42ec27bcd53531b819d7071956ffe8cf)
bkoz = Benjamin Kosnik <bkoz@gnu.org>
loewis = Martin v. Löwis (0e05896b2defbbd8261e37f284d6cccea1aca0ae)
loewis = Martin v. Löwis (a15d0e0570614c3dca749bde2c2078919a80a987)
bkoz = Benjamin Kosnik <bkoz@purist.redhat.soma.com>
aoliva = Alexandre Oliva <oliva@lsd.ic.unicamp.br>
drepper = Ulrich Drepper <drepper@redhat.com>
aoliva = Alexandre Oliva <aoliva@cygnus.com>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
jason = Jason Merrill <jason@casey.soma.redhat.com>
bkoz = Benjamin Kosnik <bkoz@milou.soma.redhat.com>
rearnsha = Richard Earnshaw <rearnsha@arm.com>
mmitchel = Mark Mitchell <mitchell@codesourcery.com>
mmitchel = Mark Mitchell <mark@codesourcery.com>
pthomas = Philipp Thomas <pthomas@suse.de>
jason = Jason Merrill <jason@redhat.com>
jason = Jason Merrill <jason@decepticon.cygnus.com>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
bkoz = Benjamin Kosnik <bkoz@gnu.org>
jason = Jason Merrill <jason@redhat.com>
jason = Jason Merrill <jason@casey.soma.redhat.com>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
tromey = Tom Tromey <tromey@ferrule.cygnus.com>
jason = Jason Merrill <jason@redhat.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
chelf = Ben Chelf (92915e1cf8e54099d4a801295525821e497fba4c)
chelf = Ben Chelf (e344117c14fc74e6f5f9c2a92877212cb5ba2038)
tromey = Tom Tromey <tromey@cygnus.com>
chelf = Ben Chelf (51444f0d6cc406e37f802123bb38208bc3c66ab7)
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
chelf = Ben Chelf (8036397fb74ba23625cf9d7a50ae46ff7c22e7db)
bkoz = Benjamin Kosnik <bkoz@soma.redhat.com>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
bkoz = Benjamin Kosnik <bkoz@soma.redhat.com>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
gdr = Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr>
rth = Richard Henderson <rth@redhat.com>
loewis = Martin v. Löwis (3359b21c9c5f89382337d0dd82e6d01788fd0632)
rth = Richard Henderson <rth@cygnus.com>
jason = Jason Merrill <jason@casey.cygnus.com>
chelf = Ben Chelf (5c3247a9c67fcadf2864d92afe12e2d02db49897)
chelf = Ben Chelf (0fabad1856707cfe69566454a8ac870ff3a39b78)
chelf = Ben Chelf (752e275be0b5b673175a1559bd4242335492d8f8)
jason = Jason Merrill <jason@redhat.com>
bkoz = Benjamin Kosnik <bkoz@gnu.org>
bkoz = Benjamin Kosnik <bkoz@soma.redhat.com>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
chelf = Ben Chelf (389acd0a1c55fa82c7702b22cd1644d4450dfa63)
chelf = Ben Chelf (9b4c18417425fc79239a47b789e47f1b5460dd2f)
aoliva = Alexandre Oliva <aoliva@redhat.com>
bkoz = Benjamin Kosnik <bkoz@milou.soma.redhat.com>
tromey = Tom Tromey <tromey@redhat.com>
bkoz = Benjamin Kosnik <bkoz@cygnus.com>
cgf = Christopher Faylor <cgf@redhat.com>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
oldham = Jeffrey D. Oldham <oldham@codesourcery.com>
tromey = Tom Tromey <tromey@cygnus.com>
aldyh = Aldy Hernandez <aldyh@redhat.com>
bkoz = Benjamin Kosnik <bkoz@haight.constant.com>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
echristo = Eric Christopher <echristo@redhat.com>
echristo = Eric Christopher <echristo@cygnus.com>
rolfwr = Rolf Rasmussen (20509bc3d8e00d8ef599963a491a1d8f6ab83a3e)
bkoz = Benjamin Kosnik <bkoz@gnu.org>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
m.hayes = Michael Hayes <mph@paradise.net.nz>
green = Anthony Green <green@redhat.com>
bkoz = Benjamin Kosnik <bkoz@cygnus.com>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
manfred = Manfred Hollstein <manfredh@redhat.com>
jsm28 = Joseph Myers <jsm28@cam.ac.uk>
m.hayes = Michael Hayes <mhayes@cygnus.com>
dj = DJ Delorie <dj@redhat.com>
dj = DJ Delorie <dj@delorie.com>
nickc = Nick Clifton <nickc@redhat.com>
bkoz = Benjamin Kosnik <bkoz@cygnus.com>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
nickc = Nick Clifton <nickc@cygnus.com>
bkoz = Benjamin Kosnik <bkoz@gnu.org>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
rolfwr = Rolf Rasmussen (73c87b405d1e5344eeae341c80432ecf3e796ca2)
gdr = Gabriel Dos Reis <gdr@merlin.codesourcery.com>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
bkoz = Benjamin Kosnik <bkoz@gnu.org>
nickc = Nick Clifton <nickc@redhat.com>
mark = Mark Wielaard <mark@klomp.org>
gdr = Gabriel Dos Reis <gdr@merlin.codesourcery.com>
dj = DJ Delorie <dj@redhat.com>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
scox = Stan Cox <scox@redhat.com>
gkm = Greg McGary <greg@mcgary.org>
pme = Phil Edwards <pme@sources.redhat.com>
obrien = David O'Brien <obrien@FreeBSD.org>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
bkoz = Benjamin Kosnik <bkoz@cygnus.com>
aph = Andrew Haley <aph@redhat.com>
green = Anthony Green <green@cygnus.com>
green = Anthony Green <green@redhat.com>
crux = Bernd Schmidt <bernds@redhat.co.uk>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
bkoz = Benjamin Kosnik <bkoz@cygnus.com>
clm = Catherine Moore <clm@redhat.com>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
ciceron = Stephane Carrez <Stephane.Carrez@worldnet.fr>
robertl = Robert Lipe <robertl@sco.com>
wcohen = William Cohen <wcohen@redhat.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
kazu = Kazu Hirata <kazu@hxi.com>
espie = Marc Espie <espie@cvs.openbsd.org>
neil = Neil Booth <neilb@earthling.net>
espie = Marc Espie <espie@openbsd.org>
obrien = David O'Brien <obrien@dragon.nuxi.com>
m.hayes = Michael Hayes <m.hayes@elec.canterbury.ac.nz>
bkoz = Benjamin Kosnik <bkoz@gnu.org>
bkoz = Benjamin Kosnik <bkoz@cygnus.com>
bkoz = Benjamin Kosnik <bkoz@fillmore.constant.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
vmakarov = Vladimir Makarov <vmakarov@touchme.toronto.redhat.com>
bkoz = Benjamin Kosnik <bkoz@cygnus.com>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
obrien = David O'Brien <obrien@FreeBSD.org>
bkoz = Benjamin Kosnik <bkoz@gnu.org>
bernds = Bernd Schmidt <bernds@redhat.co.uk>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
grahams = Graham Stott <grahams@cygnus.co.uk>
grahams = Graham Stott <grahams@redhat.com>
m.hayes = Michael Hayes <mhayes@cygnus.com>
hp = Hans-Peter Nilsson <hp@axis.com>
rolfwr = Rolf Rasmussen (e2d342dffa63aea98643515fd3b8c782ee8bd15e)
bkoz = Benjamin Kosnik <bkoz@redhat.com>
aph = Andrew Haley <aph@cygnus.co.uk>
rth = Richard Henderson <rth@redhat.com>
bernds = Bernd Schmidt <bernds@cygnus.co.uk>
zack = Zack Weinberg <zack@wolery.stanford.edu>
bernds = Bernd Schmidt <bernds@redhat.co.uk>
m.hayes = Michael Hayes <mhayes@redhat.com>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
wilson = Jim Wilson <wilson@redhat.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
cgf = Christopher Faylor <cgf@cygnus.com>
obrien = David O'Brien <obrien@dragon.nuxi.com>
pme = Phil Edwards <pedwards@jaj.com>
geoffk = Geoffrey Keating <geoffk@redhat.com>
echristo = Eric Christopher <echristo@redhat.com>
pme = Phil Edwards <pme@sources.redhat.com>
pb = Phil Blundell <pb@futuretv.com>
hp = Hans-Peter Nilsson <hp@axis.com>
aph = Andrew Haley <aph@redhat.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
hp = Hans-Peter Nilsson <hp@axis.com>
bje = Ben Elliston <bje@redhat.com>
shebs = Stan Shebs <shebs@apple.com>
zack = Zack Weinberg <zackw@stanford.edu>
zack = Zack Weinberg <zack@wolery.stanford.edu>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
bernds = Bernd Schmidt <bernds@redhat.com>
bernds = Bernd Schmidt <bernds@redhat.co.uk>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
dnovillo = Diego Novillo <dnovillo@redhat.com>
lerdsuwa = Kriang Lerdsuwanakij <lerdsuwa@users.sourceforge.net>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
bkoz = Benjamin Kosnik <bkoz@fillmore.constant.com>
bryce = Bryce McKinlay <bryce@abatross.co.nz>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
bryce = Bryce McKinlay <bryce@albatross.co.nz>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
obrien = David O'Brien <obrien@FreeBSD.org>
tromey = Tom Tromey <tromey@redhat.com>
korbb = Bruce Korb <bkorb@gcc.org>
tromey = Tom Tromey <tromey@cygnus.com>
warrenl = Warren Levy <warrenl@redhat.com>
korbb = Bruce Korb <bkorb@gnu.org>
bkoz = Benjamin Kosnik <bkoz@haight.redhat.com>
bkoz = Benjamin Kosnik <bkoz@fillmore.redhat.com>
bkoz = Benjamin Kosnik <bkoz@haight.redhat.com>
tromey = Tom Tromey <tromey@redhat.com>
bkoz = Benjamin Kosnik <bkoz@kredhat.com>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
mrs = Mike Stump <mrs@kankakee.wrs.com>
mrs = Mike Stump <mrs@wrs.com>
robertl = Robert Lipe <robertlipe@usa.net>
neil = Neil Booth <neil@daikokuya.demon.co.uk>
tromey = Tom Tromey <tromey@cygnus.com>
tromey = Tom Tromey <tromey@redhat.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
bkoz = Benjamin Kosnik <bkoz@fillmore.redhat.com>
bkoz = Benjamin Kosnik <bkoz@haight.redhat.com>
bkoz = Benjamin Kosnik <bkoz@fillmore.redhat.com>
m.hayes = Michael Hayes <m.hayes@elec.canterbury.ac.nz>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
bkoz = Benjamin Kosnik <bkoz@fillmore.redhat.com>
bkoz = Benjamin Kosnik <bkoz@fillmore.constant.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
bkoz = Benjamin Kosnik <bkoz@fillmore.constant.com>
bernds = Bernd Schmidt <bernds@redhat.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
bkoz = Benjamin Kosnik <bkoz@fillmore.redhat.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
alehotsky = Alan Lehotsky <apl@alum.mit.edu>
robertl = Robert Lipe <robertl@sco.com>
marekm = Marek Michalkiewicz <marekm@linux.org.pl>
m.hayes = Michael Hayes <mhayes@redhat.com>
bkoz = Benjamin Kosnik <bkoz@fillmore.redhat.com>
kenner = Richard Kenner <kenner@vlsi1.ultra.nyu>
kenner = Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
m.hayes = Michael Hayes <m.hayes@elec.canterbury.ac.nz>
dberlin = Daniel Berlin <dberlin@redhat.com>
m.hayes = Michael Hayes <mhayes@redhat.com>
m.hayes = Michael Hayes <m.hayes@elec.canterbury.ac.nz>
nathan = Nathan Sidwell <nathan@acm.org>
nathan = Nathan Sidwell <nathan@codesourcery.com>
robertl = Robert Lipe <robertlipe@usa.net>
m.hayes = Michael Hayes <mhayes@redhat.com>
obrien = David O'Brien <obrien@BSDi.com>
alehotsky = Alan Lehotsky <lehotsky@tiac.net>
gdr = Gabriel Dos Reis <gdr@merlin.codesourcery.com>
fjh = Fergus Henderson <fjh@cs.mu.oz.au>
danglin = John David Anglin <dave@hiauly1.hia.nrc.ca>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
gdr = Gabriel Dos Reis <gdr@merlin.codesourcery.com>
msokolov = Michael Sokolov <msokolov@ivan.Harhan.ORG>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
cgd = Chris Demetriou <cgd@broadcom.com>
m.hayes = Michael Hayes <m.hayes@elec.canterbury.ac.nz>
m.hayes = Michael Hayes <mhayes@redhat.com>
bkoz = Benjamin Kosnik <bkoz@kredhat.com>
law = Jeff Law <law@redhat.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
m.hayes = Michael Hayes <m.hayes@elec.canterbury.ac.nz>
bkoz = Benjamin Kosnik <bkoz@gnu.org>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
hp = Hans-Peter Nilsson <hp@axis.com>
bkoz = Benjamin Kosnik <bkoz@fillmore.constant.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
apbianco = Alexandre Petit-Bianco <apbianco@redhat.com>
gdr = Gabriel Dos Reis <gdr@merlin.codesourcery.com>
apbianco = Alexandre Petit-Bianco <apbianco@cygnus.com>
apbianco = Alexandre Petit-Bianco <apbianco@redhat.com>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
gdr = Gabriel Dos Reis <gdr@merlin.codesourcery.com>
bkoz = Benjamin Kosnik <bkoz@purist.soma.redhat.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
zack = Zack Weinberg <zackw@stanford.edu>
tromey = Tom Tromey <tromey@cygnus.com>
tromey = Tom Tromey <tromey@redhat.com>
lauras = Laurynas Biveinis <lauras@softhome.net>
jle = Jason Eckhardt <jle@redhat.com>
obrien = David O'Brien <obrien@FreeBSD.org>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
gdr = Gabriel Dos Reis <gdr@merlin.codesourcery.com>
amodra = Alan Modra <alan@linuxcare.com.au>
aph = Andrew Haley <aph@cambridge.redhat.com>
ljrittle = Loren J. Rittle <ljrittle@acm.org>
hubicka = Jan Hubicka <jh@use.cz>
hubicka = Jan Hubicka <jh@suse.cz>
aph = Andrew Haley <aph@redhat.com>
hiller = Matthew Hiller <hiller@redhat.com>
hubicka = Jan Hubicka <jH@suse.cz>
bkoz = Benjamin Kosnik <bkoz@codesourcery.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
hubicka = Jan Hubicka <jh@suse.cz>
aph = Andrew Haley <aph@cambridge.redhat.com>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
amodra = Alan Modra <amodra@one.net.au>
vmakarov = Vladimir Makarov <vmakarov@toke.toronto.redhat.com>
jason = Jason Merrill <jason_merrill@redhat.com>
amodra = Alan Modra <alan@linuxcare.com.au>
amodra = Alan Modra <amodra@one.net.au>
dberlin = Daniel Berlin <dan@cgsoftware.com>
tromey = Tom Tromey <tromey@cygnus.com>
bkoz = Benjamin Kosnik <bkoz@fillmore.constant.com>
nickc = Nick Clifton <nickc@cambridge.redhat.com>
bryce = Bryce McKinlay <bryce@waitaki.otago.ac.nz>
gavin = Gavin Romig-Koch <gavin@redhat.com>
hboehm = Hans Boehm <hans_boehm@hp.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
hjl = H.J. Lu <hjl@gnu.org>
hboehm = Hans Boehm <Hans_Boehm@hp.com>
aph = Andrew Haley <aph@redhat.com>
tromey = Tom Tromey <tromey@redhat.com>
aph = Andrew Haley <aph@cambridge.redhat.com>
bkoz = Benjamin Kosnik <bkoz@fillmore.constant.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
neil = Neil Booth <neil@cat.daikokuya.demon.co.uk>
neil = Neil Booth <neil@daikokuya.demon.co.uk>
neil = Neil Booth <neil@cat.daikokuya.demon.co.uk>
jknaggs = Jeff Knaggs <jknaggs@redhat.com>
kraai = Matt Kraai <kraai@alumni.carnegiemellon.edu>
neil = Neil Booth <neil@daikokuya.demon.co.uk>
aph = Andrew Haley <aph@redhat.com>
aph = Andrew Haley <aph@cambridge.redhat.com>
bkoz = Benjamin Kosnik <bkoz@kredhat.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
gdr = Gabriel Dos Reis <gdr@merlin.codesourcery.com>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
aph = Andrew Haley <aph@redhat.com>
gdr = Gabriel Dos Reis <gdr@merlin.codesourcery.com>
bkoz = Benjamin Kosnik <bkoz@redat.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
jsturm = Jeff Sturm <jsturm@one-point.com>
amodra = Alan Modra <amodra@bigpond.net.au>
ro = Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
bkoz = Benjamin Kosnik <bkoz@fillmore.constant.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
gdr = Gabriel Dos Reis <gdr@merlin.codesourcery.com>
hpenner = Hartmut Penner <hpenner@de.ibm.com>
neil = Neil Booth <neil@cat.daikokuya.demon.co.uk>
aph = Andrew Haley <aph@cambridge.redhat.com>
neil = Neil Booth <neil@daikokuya.demon.co.uk>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
bkoz = Benjamin Kosnik <bkoz@fillmore.constant.com>
neil = Neil Booth <neil@cat.daikokuya.demon.co.uk>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
neil = Neil Booth <neil@daikokuya.demon.co.uk>
aph = Andrew Haley <aph@redhat.com>
aph = Andrew Haley <aph@cambridge.redhat.com>
gdr = Gabriel Dos Reis <gdr@merlin.codesourcery.com>
bo = Bo Thorsen <bo@suse.co.uk>
aph = Andrew Haley <aph@redhat.com>
rsandifo = Richard Sandiford <rsandifo@redhat.com>
nicola = Nicola Pero <nicola@brainstorm.co.uk>
espie = Marc Espie <espie@cvs.openbsd.org>
neil = Neil Booth <neil@cat.daikokuya.demon.co.uk>
nicola = Nicola Pero <n.pero@mi.flashnet.it>
neil = Neil Booth <neil@daikokuya.demon.co.uk>
clm = Catherine Moore <clm@cygnus.com>
clm = Catherine Moore <clm@redhat.com>
neil = Neil Booth <neil@cat.daikokuya.demon.co.uk>
neil = Neil Booth <neil@daikokuya.demon.co.uk>
hp = Hans-Peter Nilsson <hp@bitrange.com>
uweigand = Ulrich Weigand <uweigand@de.ibm.com>
cpopetz = Clinton Popetz <cpopetz@cpopetz.com>
neil = Neil Booth <neil@cat.daikokuya.demon.co.uk>
aph = Andrew Haley <aph@cambridge.redhat.com>
neil = Neil Booth <neil@daikokuya.demon.co.uk>
aph = Andrew Haley <aph@redhat.com>
neil = Neil Booth <neil@cat.daikokuya.demon.co.uk>
aph = Andrew Haley <aph@cambridge.redhat.com>
cagney = Andrew Cagney <ac131313@redhat.com>
robertl = Robert Lipe <robertl@caldera.com>
neil = Neil Booth <neil@daikokuya.demon.co.uk>
zack = Zack Weinberg <zackw@panix.com>
zack = Zack Weinberg <zackw@stanford.edu>
aph = Andrew Haley <aph@redhat.com>
zack = Zack Weinberg <zackw@panix.com>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
gdr = Gabriel Dos Reis <gdr@merlin.codesourcery.com>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
gdr = Gabriel Dos Reis <gdr@merlin.codesourcery.com>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
gdr = Gabriel Dos Reis <gdr@merlin.codesourcery.com>
espie = Marc Espie <espie@openbsd.org>
janis = Janis Johnson <janis187@us.ibm.com>
aph = Andrew Haley <aph@cambridge.redhat.com>
vmakarov = Vladimir Makarov <vmakarov@touchme.toronto.redhat.com>
vmakarov = Vladimir Makarov <vmakarov@redhat.com>
zack = Zack Weinberg <zack@codesourcery.com>
hp = Hans-Peter Nilsson <hp@axis.com>
tromey = Tom Tromey <tromey@cygnus.com>
tromey = Tom Tromey <tromey@redhat.com>
zack = Zack Weinberg <zackw@panix.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
hp = Hans-Peter Nilsson <hp@axis.com>
pme = Phil Edwards <pme@gcc.gnu.org>
rearnsha = Richard Earnshaw <reanrsha@arm.com>
rearnsha = Richard Earnshaw <rearnsha@arm.com>
zack = Zack Weinberg <zack@codesourcery.com>
bosch = Geert Bosch <bosch@gnat.com>
billingd = David Billinghurst <David.Billinghurst@riotinto.com>
robertl = Robert Lipe <robertlipe@usa.net>
cgf = Christopher Faylor <cgf@redhat.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
hp = Hans-Peter Nilsson <hp@axis.com>
amylaar = Joern Rennecke <amylaar@onetel.net.uk>
trix = Tom Rix <trix@redhat.com>
collison = Michael Collison <collison@isisinc.net>
collison = Michael Collison <collison@dhcp-12-114.townisp.com>
collison = Michael Collison <collison@isisinc.net>
hp = Hans-Peter Nilsson <hp@bitrange.com>
brendan = Brendan Kehoe <brendan@zen.org>
kenner = Richard Kenner <kenner@vlsi1.ultra.nyu>
kenner = Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
dalej = Dale Johannesen <dalej@apple.com>
hp = Hans-Peter Nilsson <hp@axis.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
neil = Neil Booth <neil@cat.daikokuya.demon.co.uk>
guerby = Laurent Guerby <guerby@acm.org>
neil = Neil Booth <neil@daikokuya.demon.co.uk>
tromey = Tom Tromey <tromey@cygnus.com>
rodrigc = Craig Rodrigues <rodrigc@gcc.gnu.org>
tromey = Tom Tromey <tromey@redhat.com>
alanm = Alan Matsuoka <alanm@redhat.com>
jason = Jason Merrill <jason@redhat.com>
aph = Andrew Haley <aph@redhat.com>
hp = Hans-Peter Nilsson <hp@axis.com>
ian = Ian Lance Taylor <ian@airs.com>
zlaski = Ziemowit Laski <zlaski@apple.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
hp = Hans-Peter Nilsson <hp@axis.com>
loewis = Martin v. Löwis (ad35ef4b1489866512d2a818803b1f2be2fd2158)
paolo = Paolo Carlini <pcarlini@unitus.it>
turly = Turly O'Connor <turly@apple.com>
ciceron = Stephane Carrez <Stephane.Carrez@sun.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
doko = Matthias Klose <doko@debian.org>
loewis = Martin v. Löwis (17dc84dcaa43096de6ac9785d074c8749bade8a1)
hp = Hans-Peter Nilsson <hp@axis.com>
ira = Ira Ruben <ira@apple.com>
nicola = Nicola Pero <nicola@brainstorm.co.uk>
fw = Florian Weimer <fw@deneb.enyo.de>
bkoz = Benjamin Kosnik <bkoz@waller.constant.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
thorpej = Jason Thorpe <thorpej@wasabisystems.com>
dberlin = Daniel Berlin <dan@dberlin.org>
rodrigc = Craig Rodrigues <crodrigu@bbn.com>
rodrigc = Craig Rodrigues <rodrigc@gcc.gnu.org>
marekm = Marek Michalkiewicz <marekm@amelek.gda.pl>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
nicola = Nicola Pero <n.pero@mi.flashnet.it>
tromey = Tom Tromey <tromey@cygnus.com>
tromey = Tom Tromey <tromey@redhat.com>
hp = Hans-Peter Nilsson <hp@axis.com>
nickc = Nick Clifton <nickc@redhat.com>
bwilson = Bob Wilson <bob.wilson@acm.org>
hp = Hans-Peter Nilsson <hp@bitrange.com>
nickc = Nick Clifton <nickc@cambridge.redhat.com>
ljrittle = Loren J. Rittle <rittle@labs.mot.com>
ljrittle = Loren J. Rittle <ljrittle@acm.org>
tromey = Tom Tromey <tromey@cygnus.com>
tromey = Tom Tromey <tromey@redhat.com>
hp = Hans-Peter Nilsson <hp@axis.com>
aph = Andrew Haley <aph@cambridge.redhat.com>
nferrier = Nic Ferrier <nferrier@tf1.tapsellferrier.co.uk>
nferrier = Nic Ferrier <nferrier@tapsellferrier.co.uk>
megacz = Adam Megacz <adam@xwt.org>
hp = Hans-Peter Nilsson <hp@bitrange.com>
billingd = David Billinghurst <Davod.Billinghurst@riotinto.com>
billingd = David Billinghurst <David.Billinghurst@riotinto.com>
joel = Joel Sherrill <joel@OARcorp.com>
hp = Hans-Peter Nilsson <hp@axis.com>
ericb = Eric Blake <ebb9@email.byu.edu>
hp = Hans-Peter Nilsson <hp@bitrange.com>
bo = Bo Thorsen <bo@suse.de>
matz = Michael Matz <matz@suse.de>
dannysmith = Danny Smith <dannysmith@users.sourceforge.net>
hp = Hans-Peter Nilsson <hp@axis.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
ciceron = Stephane Carrez <Stephane.Carrez@worldnet.fr>
amylaar = Joern Rennecke <joern.rennecke@superh.com>
aph = Andrew Haley <aph@redhat.com>
dannysmith = Danny Smith <dannysmith@sourceforge.users.net>
dannysmith = Danny Smith <dannysmith@users.sourceforge.net>
aph = Andrew Haley <aph@cambridge.redhat.com>
gingell = Matthew Gingell <gingell@gnat.com>
aph = Andrew Haley <aph@redhat.com>
hp = Hans-Peter Nilsson <hp@axis.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
hp = Hans-Peter Nilsson <hp@axis.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
hp = Hans-Peter Nilsson <hp@axis.com>
aph = Andrew Haley <aph@cambridge.redhat.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
hp = Hans-Peter Nilsson <hp@axis.com>
aph = Andrew Haley <aph@redhat.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
bo = Bo Thorsen <bo@suse.co.uk>
sayle = Roger Sayle <roger@eyesopen.com>
kazu = Kazu Hirata <kazu@cs.umass.edu>
timjosling = Tim Josling <tej@melbpc.org.au>
ciceron = Stephane Carrez <stcarrez@nerim.fr>
rakdver = Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz>
mmitchel = Mark Mitchell <mitchell@doubledemon.codesourcery.com>
mmitchel = Mark Mitchell <mark@codesourcery.com>
kkojima = Kaz Kojima <kkojima@gcc.gnu.org>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
bo = Bo Thorsen <bo@suse.de>
hp = Hans-Peter Nilsson <hp@axis.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
alehotsky = Alan Lehotsky <apl@alum.mit.edu>
dberlin = Daniel Berlin <dberlin@dberlin.org>
gdr = Gabriel Dos Reis <gdr@merlin.nerim.net>
gdr = Gabriel Dos Reis <gdr@codesourcery.com>
hp = Hans-Peter Nilsson <hp@axis.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
dannysmith = Danny Smith <dannysmith@users.sourforge.net>
hp = Hans-Peter Nilsson <hp@axis.com>
tromey = Tom Tromey <tromey@cygnus.com>
tromey = Tom Tromey <tromey@redhat.com>
rupp = Douglas Rupp <rupp@gnat.com>
law = Jeff Law <law@redha.com>
kraai = Matt Kraai <kraai@alumni.cmu.edu>
neil = Neil Booth <neil@daikokuya.co.uk>
law = Jeff Law <law@redhat.com>
sje = Steve Ellcey <sje@cup.hp.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
neroden = Nathanael Nerode <neroden@gcc.gnu.org>
ciceron = Stephane Carrez <Stephane.Carrez@nerim.fr>
ciceron = Stephane Carrez <stcarrez@nerim.fr>
grahams = Graham Stott <graham.stott@btinternet.com>
neil = Neil Booth <neil@daikokuya.demon.co.uk>
neil = Neil Booth <neil@daikokuya.co.uk>
neroden = Nathanael Nerode <neroden@twcny.rr.com>
hp = Hans-Peter Nilsson <hp@axis.com>
neroden = Nathanael Nerode <neroden@gcc.gnu.org>
dpatel = Devang Patel <dpatel@apple.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
gdr = Gabriel Dos Reis <gdr@nerim.net>
hp = Hans-Peter Nilsson <hp@axis.com>
bo = Bo Thorsen <bo@berlioz.suse.de>
bo = Bo Thorsen <bo@suse.de>
bo = Bo Thorsen <bo@berlioz.suse.de>
mrs = Mike Stump <mrs@apple.com>
aldyh = Aldy Hernandez <aldy@quesejoda.com>
aldyh = Aldy Hernandez <aldyh@redhat.com>
danglin = John David Anglin <dave@hiauly1.hia.nrc>
grahams = Graham Stott <grahams@btinternet.com>
grahams = Graham Stott <grahas@btinternet.com>
grahams = Graham Stott <grahams@btinternet.com>
danglin = John David Anglin <dave@hiauly1.hia.nrc.ca>
drow = Daniel Jacobowitz <drow@mvista.com>
kristerw = Krister Walfridsson <cato@df.lth.se>
hp = Hans-Peter Nilsson <hp@bitrange.com>
aph = Andrew Haley <aph@cambridge.redhat.com>
gdr = Gabriel Dos Reis <gdr@integrable-solutions.net>
mkoch = Michael Koch <konqueror@gmx.de>
gdr = Gabriel Dos Reis <gdr@soliton.integrable-solutions.net>
austern = Matt Austern <austern@apple.com>
nickc = Nick Clifton <nickc@redhat.com>
gdr = Gabriel Dos Reis <gdr@integrable-solutions.net>
rearnsha = Richard Earnshaw <rearnshaw@arm.com>
pkoning = Paul Koning <pkoning@equallogic.com>
grahams = Graham Stott <graham.stott@btinternet.com>
aph = Andrew Haley <aph@redhat.com>
grahams = Graham Stott <graham.stott@btinternet.con>
dannysmith = Danny Smith <dannysmith@users.sourceforge.net>
fche = Frank Ch. Eigler <fche@redhat.com>
rearnsha = Richard Earnshaw <rearnsha@arm.com>
gdr = Gabriel Dos Reis <gdr@soliton.integrable-solutions.net>
geoffk = Geoffrey Keating <geoffk@apple.com>
geoffk = Geoffrey Keating <geoffk@redhat.com>
rearnsha = Richard Earnshaw <reanrsha@arm.com>
geoffk = Geoffrey Keating <geoffk@apple.com>
danglin = John David Anglin <dave@hiuly1.hia.nrc.ca>
rearnsha = Richard Earnshaw <rearnsha@arm.com>
neroden = Nathanael Nerode <neroden@doctor.moo.mud.org>
neroden = Nathanael Nerode <neroden@gcc.gnu.org>
danglin = John David Anglin <dave@hiauly1.hia.nrc.ca>
hp = Hans-Peter Nilsson <hp@axis.com>
bo = Bo Thorsen <bo@suse.de>
hp = Hans-Peter Nilsson <hp@bitrange.com>
bo = Bo Thorsen <bo@smetana.suse.de>
gdr = Gabriel Dos Reis <gdr@integrable-solutions.net>
grahams = Graham Stott <graham.stott@btinternet.com>
spop = Sebastian Pop <s.pop@laposte.net>
danglin = John David Anglin <dave@hiauly.hia.nrc.ca>
danglin = John David Anglin <dave@hiauly1.hia.nrc.ca>
kevinb = Kevin Buettner <kevinb@redhat.com>
nemet = Adam Nemet <anemet@lnxw.com>
redi = Jonathan Wakely <redi@gcc.gnu.org>
stuart = Stuart Hastings <stuart@apple.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
hubicka = Jan Hubicka <jH@suse.cz>
hubicka = Jan Hubicka <jh@suse.cz>
sveinse = Svein Seldal <svein.seldal@solidas.com>
dpatel = Devang Patel <dpatel@appple.com>
dpatel = Devang Patel <dpatel@apple.com>
devans = Doug Evans <dje@transmeta.com>
devans = Doug Evans <dje@sebabeach.org>
zlomek = Josef Zlomek <zlomek@matfyz.cz>
zlomek = Josef Zlomek <zlomekj@suse.cz>
danglin = John David Anglin <dave.anglin@nrc.gc.ca>
danglin = John David Anglin <dave.anglin@nrc.ca>
danglin = John David Anglin <dave@hiauly1.hia.nrc.ca>
zlomek = Josef Zlomek <zlomj9am@artax.karlin.mff.cuni.cz>
zlomek = Josef Zlomek <zlomekj@suse.cz>
danglin = John David Anglin <dave.anglin@nrc.gc.ca>
danglin = John David Anglin <dave@hiauly1.hia.nrc.ca>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
reichelt = Volker Reichelt <reichelt@igpm.rwth-aachen.de>
m.hayes = Michael Hayes <mph@paradise.net.nz>
gdr = Gabriel Dos Reis <gdr@soliton.integrable-solutions.net>
gdr = Gabriel Dos Reis <gdr@integrable-solutions.net>
fjahanian = Fariborz Jahanian <fjahanian@apple.com>
andreast = Andreas Tobler <a.tobler@schweiz.ch>
ccorn = Christian Cornelssen <ccorn@cs.tu-berlin.de>
aph = Andrew Haley <aph@emcee.cambridge.redhat.com>
aph = Andrew Haley <aph@redhat.com>
hboehm = Hans Boehm <Hans.Boehm@hp.com>
lauras = Laurynas Biveinis <laurynas.biveinis@mif.vu.lt>
bkoz = Benjamin Kosnik <benjamin@redhat.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
danglin = John David Anglin <dave.anglin@nrc-crnc.gc.ca>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
wilson = Jim Wilson <wilson@tuliptree.org>
hp = Hans-Peter Nilsson <hp@axis.com>
steven = Steven Bosscher <steven@gcc.gnu.org>
vmakarov = Vladimir Makarov <vmakarov@toke.toronto.redhat.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
jlquinn = Jerry Quinn <jlquinn@optonline.net>
vmakarov = Vladimir Makarov <vmakarov@redhat.com>
bje = Ben Elliston <bje@wasabisystems.com>
steven = Steven Bosscher <s.bosscher@student.tudelft.nl>
mkoch = Michael Koch <koqnueror@gmx.de>
mkoch = Michael Koch <konqueror@gmx.de>
hp = Hans-Peter Nilsson <hp@axis.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
ansgar = Ansgar Esztermann <ansgar@thphy.uni-duesseldorf.de>
steven = Steven Bosscher <steven@gcc.gnu.org>
m.hayes = Michael Hayes <m.hayes@elec.canterbury.ac.nz>
hainque = Olivier Hainque <hainque@act-europe.fr>
bothner = Per Bothner <pbothner@apple.com>
mkoch = Michael Koch <koqnueror@gmx.de>
mkoch = Michael Koch <konqueror@gmx.de>
hp = Hans-Peter Nilsson <hp@axis.com>
joel = Joel Sherrill <joel@oarcorp.com>
janis = Janis Johnson <janis287@us.ibm.com>
janis = Janis Johnson <janis187@us.ibm.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
jkj = Kean Johnston <jkj@sco.com>
bkoz = Benjamin Kosnik <bkoz@belmont.constant.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
bangerth = Wolfgang Bangerth <bangerth@dealii.org>
gerald = Gerald Pfeifer <gerald@sourceware.org>
neil = Neil Booth <neil@cat.daikokuya.co.uk>
meissner = Michael Meissner <gnu@the-meissners.org>
gerald = Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
neil = Neil Booth <neil@daikokuya.co.uk>
neil = Neil Booth <neil@cat.daikokuya.co.uk>
neil = Neil Booth <neil@daikokuya.co.uk>
danglin = John David Anglin <dave.anglin@nrc-gnrc.gc.ca>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
hjl = H.J. Lu <hongjiu.lu@intel.com>
hp = Hans-Peter Nilsson <hp@axis.com>
kkojima = Kaz Kojima <kkojima@rr.iij4u.or.jp>
kkojima = Kaz Kojima <kkojima@gcc.gnu.org>
gp = Graeme Peterson <gp@qnx.com>
dgregor = Doug Gregor <dgregor@apple.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
hp = Hans-Peter Nilsson <hp@axis.com>
bangerth = Wolfgang Bangerth <bangerth@ices.utexas.edu>
fitzsim = Thomas Fitzsimmons <fitzsim@redhat.com>
manfred = Manfred Hollstein <mh@suse.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
gdr = Gabriel Dos Reis <gcc@integrable-solutions.net>
gdr = Gabriel Dos Reis <gdr@integrable-solutions.net>
gdr = Gabriel Dos Reis <gcc@integrable-solutions.net>
gdr = Gabriel Dos Reis <gdr@integrable-solutions.net>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
graydon = Graydon Hoare <graydon@redhat.com>
bangerth = Wolfgang Bangerth <bangerth@dealii.org>
sgilbertson = Scott Gilbertson <scottg@mantatest.com>
pbrook = Paul Brook <paul@nowt.org>
cagney = Andrew Cagney <cagney@redhat.com>
rsandifo = Richard Sandiford <rsandif@redhat.com>
bryce = Bryce McKinlay <bryce@mckinlay.net.nz>
rsandifo = Richard Sandiford <rsandifo@redhat.com>
bothner = Per Bothner <per@bothner.com>
bothner = Per Bothner <pbothner@apple.com>
membar = Mohan Embar <gnustuff@thisiscool.com>
gerald = Gerald Pfeifer <gerald@pfeifer.com>
iandall = Ian Dall <ian@beware.dropbear.id.au>
bernie = Bernardo Innocenti <bernie@develer.com>
bothner = Per Bothner <bothner@pbothner.com>
jle = Jason Eckhardt <jle@rice.edu>
neroden = Nathanael Nerode <neroden@twcny.rr.com>
neroden = Nathanael Nerode <neroden@gcc.gnu.org>
bothner = Per Bothner <pbothner@apple.com>
bothner = Per Bothner <per@bothner.com>
pme = Phil Edwards <phil@codesourcery.com>
wilson = Jim Wilson <wilson@specifixinc.com>
gdr = Gabriel Dos Reis <gcc@integrable-solutions.net>
ian = Ian Lance Taylor <ian@wasabisystems.com>
dalej = Dale Johannesen <dale@apple.com>
dalej = Dale Johannesen <dalej@apple.com>
brobecke = Joel Brobecker <brobecker@gnat.com>
gdr = Gabriel Dos Reis <gdr@integrable-solutions.net>
pinskia = Andrew Pinski <apinski@apple.com>
grahams = Graham Stott <grahams@btinternet.com>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
gdr = Gabriel Dos Reis <gcc@integrable-solutions.net>
pinskia = Andrew Pinski <apinski@apple.com>
gdr = Gabriel Dos Reis <gdr@integrable-solutions.net>
bothner = Per Bothner <pbothner@apple.com>
grahams = Graham Stott <graham.stott@btinternet.com>
pkoning = Paul Koning <ni1d@arrl.net>
carlo = Carlo Wood <carlo@alinoe.com>
bowdidge = Robert Bowdidge <bowdidge@apple.com>
rearnsha = Richard Earnshaw <reanrsha@arm.com>
rearnsha = Richard Earnshaw <rearnsha@arm.com>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
falk = Falk Hueffner <falk@debian.org>
hp = Hans-Peter Nilsson <hp@axis.com>
daney = David Daney <ddaney@avtrex.com>
paolo = Paolo Carlini <pcarlini@suse.de>
ralph = Ralph Loader <rcl@ihug.co.nz>
hp = Hans-Peter Nilsson <hp@bitrange.com>
nico = Nicolas Pitre <nico@cam.org>
jsm28 = Joseph Myers <jsm@polyomino.org.uk>
charlet = Arnaud Charlet <charlet@act-europe.fr>
falk = Falk Hueffner <falk.hueffner@student.uni-tuebingen.de>
hp = Hans-Peter Nilsson <hp@axis.com>
bothner = Per Bothner <per@bothner.com>
spolk = Syd Polk <spolk@apple.com>
bothner = Per Bothner <pbothner@apple.com>
falk = Falk Hueffner <falk@debian.org>
steven = Steven Bosscher <stevenb@suse.de>
pinskia = Andrew Pinski <apinski@apple.com>
gerald = Gerald Pfeifer <gp@suse.de>
matt = Matt Thomas <matt@3am-software.com>
jwlemke = James Lemke <jim@wasabisystems.com>
giovannibajo = Giovanni Bajo <giovannibajo@gcc.gnu.org>
fnasser = Fernando Nasser <fnasser@redhat.com>
geoffk = Geoffrey Keating <geoffk@geoffk.org>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
rearnsha = Richard Earnshaw <reanrsha@arm.com>
rearnsha = Richard Earnshaw <rearnsha@arm.com>
geoffk = Geoffrey Keating <geoffk@apple.com>
paolo = Paolo Carlini <pcaelini@suse.de>
paolo = Paolo Carlini <pcarlini@suse.de>
steven = Steven Bosscher <steven@gcc.gnu.org>
steven = Steven Bosscher <stevenb@suse.de>
bothner = Per Bothner <per@bothner.com>
steven = Steven Bosscher <steven@gcc.gnu.org>
pinskia = Andrew Pinski <pinskia@gcc.gnu.org>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
geoffk = Geoffrey Keating <geoffk@greed.local>
hp = Hans-Peter Nilsson <hp@bitrange.com>
dann = Dan Nicolaescu <dann@ics.uci.edu>
geoffk = Geoffrey Keating <geoffk@apple.com>
djee = David Jee <djee@redhat.com>
steven = Steven Bosscher <stevenb@suse.de>
pbrook = Paul Brook <paul@codesourcery.com>
geoffk = Geoffrey Keating <geoffk@greed.local>
geoffk = Geoffrey Keating <geoffk@apple.com>
pinskia = Andrew Pinski <apinski@apple.com>
rodimina = Olga Rodimina <rodimina@redhat.com>
kho = Kim Ho <kho@redhat.com>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
gerald = Gerald Pfeifer <gerald@pfeifer.com>
phython = James A. Morrison <ja2morri@uwaterloo.ca>
bothner = Per Bothner <pbothner@apple.com>
bothner = Per Bothner <per@bothner.com>
ctice = Caroline Tice <ctice@apple.com>
pinskia = Andrew Pinski <apinski@apple.com>
ebotcazou = Eric Botcazou <ebotcazou@act-europe.fr>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@act-europe.fr>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
geoffk = Geoffrey Keating <geoffk@geoffk.org>
steven = Steven Bosscher <s.bosscher@student.tudelft.nl>
charlet = Arnaud Charlet <charlet@gnat.com>
giovannibajo = Giovanni Bajo <giovannibajo@libero.it>
pkoning = Paul Koning <pkoning@equallogic.com>
giovannibajo = Giovanni Bajo <giovannibajo@gcc.gnu.org>
geoffk = Geoffrey Keating <geoffk@apple.com>
bonzini = Paolo Bonzini <bonzini@gnu.org>
charlet = Arnaud Charlet <charlet@act-europe.fr>
ebotcazou = Eric Botcazou <ebotcazou@act-europe.fr>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
steven = Steven Bosscher <stevenb@suse.de>
hp = Hans-Peter Nilsson <hp@axis.com>
ebotcazou = Eric Botcazou <ebotcazou@act-europe.fr>
kcook = R. Kelley Cook <kcook@gcc.gnu.org>
pinskia = Andrew Pinski <apinski@apple.com>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
bbooth = Brian Booth <bbooth@redhat.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@act-europe.fr>
pinskia = Andrew Pinski <apinski@apple.com>
bje = Ben Elliston <bje@gnu.org>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
bje = Ben Elliston <bje@wasabisystems.com>
pinskia = Andrew Pinski <apinski@apple.com>
ebotcazou = Eric Botcazou <ebotcazou@act-europe.fr>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
pinskia = Andrew Pinski <pinskia@gcc.gnu.org>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
pbrook = Paul Brook <paul@nowt.org>
pbrook = Paul Brook <paul@codesourcery.com>
bdavis = Bud Davis <bdavis9659@comcast.net>
rmathew = Ranjit Mathew <rmathew@hotmail.com>
chastain = Michael Chastain <mec.gnu@mindspring.com>
bryce = Bryce McKinlay <mckinlay@redhat.com>
danglin = John David Anglin <dava.anglin@nrc-cnrc.gc.ca>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
guerby = Laurent Guerby <laurent@guerby.net>
hp = Hans-Peter Nilsson <hp@bitrange.com>
bje = Ben Elliston <bje@au.ibm.com>
uros = Uros Bizjak <uros@kss-loka.si>
ford = Brian Ford <ford@vss.fsi.com>
ebotcazou = Eric Botcazou <ebotcazou@act-europe.fr>
hp = Hans-Peter Nilsson <hp@axis.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@act-europe.fr>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
pinskia = Andrew Pinski <pinskia@gcc.gnu.org>
tobi = Tobias Schlüter <tobi@gcc.gnu.org>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
rearnsha = Richard Earnshaw <reanrsha@arm.com>
rearnsha = Richard Earnshaw <rearnsha@arm.com>
drow = Daniel Jacobowitz <dan@debian.org>
hagog = Mostafa Hagog <hagog@gcc.gnu.org>
hagog = Mostafa Hagog <mustafa@il.ibm.com>
drow = Daniel Jacobowitz <drow@false.org>
ebotcazou = Eric Botcazou <ebotcazou@act-europe.fr>
drow = Daniel Jacobowitz <dan@debian.org>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@act-europe.fr>
mgadams = Mark G. Adams <mark.g.adams@sympatico.ca>
davem = David S. Miller <davem@nuts.davemloft.net>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
canqun = Canqun Yang <canqun@nudt.edu.cn>
jonz = Jon Ziegler <jonz@apple.com>
ebotcazou = Eric Botcazou <ebotcazou@act-europe.fr>
pinskia = Andrew Pinski <apinski@apple.com>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
pinskia = Andrew Pinski <apinski@apple.com>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
matthewg = Matthew Sachs <msachs@apple.com>
cgf = Christopher Faylor <cgf@alum.bu.edu>
pinskia = Andrew Pinski <apinski@apple.com>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
pinskia = Andrew Pinski <apinski@apple.com>
spop = Sebastian Pop <pop@cri.ensmp.fr>
neil = Neil Booth <neil@duron.akihabara.co.uk>
segher = Segher Boessenkool <segher@kernel.crashing.org>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
ebotcazou = Eric Botcazou <ebotcazou@act-europe.fr>
gdr = Gabriel Dos Reis <gdr@integrable-solution.net>
danglin = John David Anglin <dava.anglin@nrc-cnrc.gc.ca>
pinskia = Andrew Pinski <apinski@apple.com>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
gdr = Gabriel Dos Reis <gdr@integrable-solutions.net>
pinskia = Andrew Pinski <apinski@apple.com>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
gdr = Gabriel Dos Reis <gdr@cs.tamu.edu>
bonzini = Paolo Bonzini <gcc@gcc.gnu.org>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
pinskia = Andrew Pinski <apinski@apple.com>
bonzini = Paolo Bonzini <bonzini@gnu.org>
phython = James A. Morrison <phython@gcc.gnu.org>
pbrook = Paul Brook <paul@codeourcery.com>
pbrook = Paul Brook <paul@codesourcery.com>
jbeulich = Jan Beulich <jbeulich@novell.com>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
pinskia = Andrew Pinski <apinski@apple.com>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
pinskia = Andrew Pinski <apinski@apple.com>
daney = David Daney <daney@avtrex.com>
gdr = Gabriel Dos Reis <gdr@integrable-solutions.net>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
daney = David Daney <ddaney@avtrex.com>
pinskia = Andrew Pinski <apinski@apple.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
zadeck = Kenneth Zadeck <Kenneth.Zadeck@NaturalBridge.com>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
pinskia = Andrew Pinski <apinski@apple.com>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
hp = Hans-Peter Nilsson <hp@axis.com>
ebotcazou = Eric Botcazou <ebotcazou@act-europe.fr>
hp = Hans-Peter Nilsson <hp@bitrange.com>
hp = Hans-Peter Nilsson <hp@axis.com>
rakdver = Zdenek Dvorak <dvorakz@suse.cz>
bernds = Bernd Schmidt <bernds_cb1@t-online.de>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
gdr = Gabriel Dos Reis <gdr@cs.tamu.edu>
gdr = Gabriel Dos Reis <gdr@integrable-solutions.net>
zlomek = Josef Zlomek <josef.zlomek@email.cz>
zadeck = Kenneth Zadeck <zadeck@naturalbridge.com>
amylaar = Joern Rennecke <joern.rennecke@st.com>
pbrook = Paul Brook <paul@coodesourcery.com>
pbrook = Paul Brook <paul@coudesourcery.com>
pbrook = Paul Brook <paul@codesourcery.com>
jsm28 = Joseph Myers <joseph@codesourcery.com>
drow = Daniel Jacobowitz <dan@codesourcery.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
aaronwl = Aaron W. LaFramboise <aaronavay62@aaronwl.com>
drow = Daniel Jacobowitz <dan@debian.org>
geoffk = Geoffrey Keating <geoffk@redhat.com>
geoffk = Geoffrey Keating <geoffk@geoffk.org>
jsm28 = Joseph Myers <jsm@polyomino.org.uk>
geoffk = Geoffrey Keating <geoffk@apple.com>
pbrook = Paul Brook <paul@codeosurcery.com>
pbrook = Paul Brook <paul@codesourcery.com>
srladd = Scott Robert Ladd <scott.ladd@coyotegulch.com>
jsm28 = Joseph Myers <joseph@codesourcery.com>
loki = Gabor Loki <loki@inf.u-szeged.hu>
corsepiu = Ralf Corsepius <ralf.corsepius@rtems.org>
ebotcazou = Eric Botcazou <ebotcazou@act-europe.fr>
bernds = Bernd Schmidt <bernd.schmidt@analog.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
victorlei = Victor Leikehman <lei@il.ibm.com>
charlet = Arnaud Charlet <charlet@adacore.com>
redi = Jonathan Wakely <redi@kayari.org>
amacleod = Andrew Macleod <amacleod@redhat.com>
kraai = Matt Kraai <kraai@ftbfs.org>
cgf = Christopher Faylor <cgf@gcc.gnu.org>
geoffk = Geoffrey Keating <geoffk@geoffk.org>
reichelt = Volker Reichelt <reichelt@igpm.rwth-aaachen.de>
geoffk = Geoffrey Keating <geoffk@apple.com>
redi = Jonathan Wakely <redi@gcc.gnu.org>
hp = Hans-Peter Nilsson <hp@axis.com>
thorpej = Jason Thorpe <thorpej@netbsd.org>
ian = Ian Lance Taylor <ian@airs.com>
ian = Ian Lance Taylor <ian@c2micro.com>
ian = Ian Lance Taylor <ian@airs.com>
joel = Joel Sherrill <joel.sherrill@oarcorp.com>
neil = Neil Booth <neil@daikokuya.co.uk>
reichelt = Volker Reichelt <reichelt@igpm.rwth-aachen.de>
hp = Hans-Peter Nilsson <hp@bitrange.com>
ian = Ian Lance Taylor <ian@c2micro.com>
ian = Ian Lance Taylor <ian@airs.com>
drow = Daniel Jacobowitz <dan@codesourcery.com>
hp = Hans-Peter Nilsson <hp@axis.com>
ian = Ian Lance Taylor <ian@c2micro.com>
ian = Ian Lance Taylor <ian@airs.com>
bdavis = Bud Davis <bdavis@gfortran.org>
rguenth = Richard Biener;Richard Guenther <rguenth@gcc.gnu.org>
nickc = Nick Clifton <nickc@cygnus.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
razya = Razya Ladelsky <razya@gcc.gnu.org>
irar = Ira Rosen <irar@il.ibm.com>
hp = Hans-Peter Nilsson <hp@axis.com>
kargl = Steven G. Kargl <kargl@gcc.gnu.org>
kargl = Steven G. Kargl <kargls@comcast.net>
austern = Matt Austern <austern@gmail.com>
dgregor = Doug Gregor <doug.gregor@gmail.com>
jules = Julian Brown <julian@codesourcery.com>
sveinse = Svein Seldal <svein@dev.seldal.com>
kargl = Steven G. Kargl <kargl@gcc.gnu.org>
nickc = Nick Clifton <nickc@redhat.com>
dberlin = Daniel Berlin <dan@dberlin.org>
ayers = David Ayers <d.ayers@inode.at>
dberlin = Daniel Berlin <dberlin@dbrelin.org>
kargl = Steven G. Kargl <kargls@comcast.net>
danglin = John David Anglin <dave.danglin@nrc-cnrc.gc.ca>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
ian = Ian Lance Taylor <ian@cygnus.com>
ian = Ian Lance Taylor <ian@airs.com>
dberlin = Daniel Berlin <dberlin@dberlin.org>
fengwang = Feng Wang <fengwang@nudt.edu.cn>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
manfred = Manfred Hollstein <manfred.h@gmx.net>
fxcoudert = François-Xavier Coudert <coudert@clipper.ens.fr>
danglin = John David Anglin <dave.anglin@nrc-crnc.gc.ca>
gdr = Gabriel Dos Reis <gdr@integreable-solutions.net>
gdr = Gabriel Dos Reis <gdr@integrable-solutions.net>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
hainque = Olivier Hainque <hainque@adacore.com>
rakdver = Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz>
rearnsha = Richard Earnshaw <richard.earnshaw@arm.com>
jgrimm = Jon Grimm <jgrimm2@us.ibm.com>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
rakdver = Zdenek Dvorak <dvorakz@suse.cz>
tkoenig = Thomas Koenig <Thomas.Koenig@online.de>
jsm28 = Joseph Myers <jsm@polyomino.org.uk>
davem = David S. Miller <davem@davemloft.net>
pault = Paul Thomas <pault@gcc.gnu.org>
jsm28 = Joseph Myers <joseph@codesourcery.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
hp = Hans-Peter Nilsson <hp@axis.com>
rearnsha = Richard Earnshaw <rearnsha@arm.com>
rearnsha = Richard Earnshaw <richard.earnshaw@arm.com>
loki = Gabor Loki <loki@gcc.gnu.org>
davidu = David Ung <davidu@mips.com>
nathan = Nathan Sidwell <nathan@acm.org>
mrs = Mike Stump <mrs@mrs.kithrup.com>
mrs = Mike Stump <mrs@apple.com>
nathan = Nathan Sidwell <nathan@codesourcery.com>
ziga = Ziga Mahkovec <ziga.mahkovec@klika.si>
geoffk = Geoffrey Keating <geoffk@geoffk.org>
kseitz = Keith Seitz <keiths@redhat.com>
kazu = Kazu Hirata <kazu@codesourcery.com>
jconner = Josh Conner <jconner@apple.com>
jvdelisle = Jerry DeLisle <jvdelisle@verizon.net>
dorit = Dorit Nuzman <dorit@il.ibm.com>
geoffk = Geoffrey Keating <geoffk@apple.com>
rsandifo = Richard Sandiford <rsandifo@nildram.co.uk>
hp = Hans-Peter Nilsson <hp@bitrange.com>
hp = Hans-Peter Nilsson <hp@axis.com>
hp = Hans-Peter Nilsson <hp@axis.se>
hp = Hans-Peter Nilsson <hp@axis.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
gdr = Gabriel Dos Reis <gdr@cs.tamu.edu>
gdr = Gabriel Dos Reis <gdr@integrable-solutions.net>
gdr = Gabriel Dos Reis <gdr@integrable-solutions.edu>
tkoenig = Thomas Koenig <Thomas.Koenig@onlinde.de>
gdr = Gabriel Dos Reis <gdr@integrable-solutions.net>
tkoenig = Thomas Koenig <Thomas.Koenig@online.de>
rsandifo = Richard Sandiford <richard@codesourcery.com>
giovannibajo = Giovanni Bajo <giovannibajo@libero.it>
kargl = Steven G. Kargl <kargls@comast.net>
kargl = Steven G. Kargl <kargls@comcast.net>
geoffk = Geoffrey Keating <geoffk@geoffk.org>
aluchko = Aaron Luchko <aluchko@redhat.com>
hp = Hans-Peter Nilsson <hp@axis.se>
rguenth = Richard Biener;Richard Guenther <rguenther@suse.de>
zack = Zack Weinberg <zackw@panix.com>
danglin = John David Anglin <dave.anglin@nrc-crnc.gc.ca>
geoffk = Geoffrey Keating <geoffk@apple.com>
danglin = John David Anglin <dave.anglin@nrc-crc.gc.ca>
hp = Hans-Peter Nilsson <hp@axis.com>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
tromey = Tom Tromey <tromey@cygnus.com>
tromey = Tom Tromey <tromey@redhat.com>
kazu = Kazu Hirata <kazu@cs.umass.edu>
woepaul = Paul Woegerer <paul.woegerer@nsc.com>
echristo = Eric Christopher <echristo@apple.com>
bje = Ben Elliston <bje@gnu.org>
bje = Ben Elliston <bje@au.ibm.com>
bje = Ben Elliston <bje@gnu.org>
manfred = Manfred Hollstein <mh@suse.com>
rguenth = Richard Biener;Richard Guenther <rguenther@gcc.gnu.org>
rguenth = Richard Biener;Richard Guenther <rguenther@suse.de>
kazu = Kazu Hirata <kazu@codesourcery.com>
bje = Ben Elliston <bje@au.ibm.com>
razya = Razya Ladelsky <RAZYA@il.ibm.com>
razya = Razya Ladelsky <razya@il.ibm.com>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
phython = James A. Morrison <phython@gc.gnu.org>
phython = James A. Morrison <phython@gcc.gnu.org>
macro = Maciej W. Rozycki <macro@linux-mips.org>
uweigand = Ulrich Weigand <weigand@informatik.uni-erlangen.de>
uweigand = Ulrich Weigand <uweigand@de.ibm.com>
krebbel = Andreas Krebbel <krebbel1@de.ibm.com>
uweigand = Ulrich Weigand <weigand@informatik.uni-erlangen.de>
uweigand = Ulrich Weigand <uweigand@de.ibm.com>
wilson = Jim Wilson <wilson@specifix.com>
rguenth = Richard Biener;Richard Guenther <rguenther@gcc.gnu.org>
danglin = John David Anglin <dave.anflin@nrc-cnrc.gc.ca>
rguenth = Richard Biener;Richard Guenther <rguenther@suse.de>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
cgf = Christopher Faylor <cgf@timesys.com>
rmathew = Ranjit Mathew <rmathew@gcc.gnu.org>
fche = Frank Ch. Eigler <fche@elastic.org>
amacleod = Andrew Macleod <amacleod@redat.com>
clm = Catherine Moore <clm@cm00re.com>
uweigand = Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
uweigand = Ulrich Weigand <uweigand@de.ibm.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
hp = Hans-Peter Nilsson <hp@bitrange.com>
hp = Hans-Peter Nilsson <hp@axis.com>
rearnsha = Richard Earnshaw <richard.earnsahw@arm.com>
jiez = Jie Zhang <jie.zhang@analog.com>
rearnsha = Richard Earnshaw <richard.earnshaw@arm.com>
uweigand = Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
uweigand = Ulrich Weigand <uweigand@de.ibm.com>
eedelman = Erik Edelmann <erik.edelmann@iki.fi>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
eedelman = Erik Edelmann <eedelman@gcc.gnu.org>
hp = Hans-Peter Nilsson <hp@bitrange.com>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
root = Daniel Berlin <dberlin@dberlin.org>
pinskia = Andrew Pinski <pinskia@gcc.gnu.org>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
pinskia = Andrew Pinski <pinskia@gcc.gnu.org>
hp = Hans-Peter Nilsson <hp@axis.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
hp = Hans-Peter Nilsson <hp@axis.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
jb = Janne Blomqvist <jb@gcc.gnu.org>
tlaurenzo = Terry Laurenzo <tlaurenzo@gmail.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
jvdelisle = Jerry DeLisle <jvdelisle@gcc.gnu.org>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
kenner = Richard Kenner <kenner@don.gnat.com>
kenner = Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
bonzini = Paolo Bonzini <bonzini@gcc.gnu.org>
hp = Hans-Peter Nilsson <hp@bitrange.com>
hp = Hans-Peter Nilsson <hp@axis.com>
bonzini = Paolo Bonzini <bonzini@gnu.org>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
geoffk = Geoffrey Keating <geoffk@geoffk.org>
davem = David S. Miller <davem@sunset.davemloft.net>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
geoffk = Geoffrey Keating <geoffk@apple.com>
nemet = Adam Nemet <anemet@caviumnetworks.com>
ths = Thiemo Seufer <ths@networkno.de>
carlos = Carlos O'Donell <carlos@codesourcery.com>
steven = Steven Bosscher <stevenb.gcc@gmail.com>
pinskia = Andrew Pinski <pinskia@ohysics.uc.edu>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
sabre = Chris Lattner <sabre@gnu.org>
rearnsha = Richard Earnshaw <rearnsha@arm.com>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
gdr = Gabriel Dos Reis <gdr@integrablesolutions.net>
hp = Hans-Peter Nilsson <hp@axis.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
gdr = Gabriel Dos Reis <gdr@integrable-solutions.net>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
mueller = Dirk Mueller <dmueller@suse.de>
rth = Richard Henderson <rth@redehat.com>
bergner = Peter Bergner <bergner@vnet.ibm.com>
rearnsha = Richard Earnshaw <richard.earnshaw@arm.com>
gdr = Gabriel Dos Reis <gdr@cs.tamu.edu>
gdr = Gabriel Dos Reis <gdr@integrable-solutions.net>
gdr = Gabriel Dos Reis <gdr@integgrable-solutions.net>
gdr = Gabriel Dos Reis <gdr@integrable-solutions.net>
dalecki = Marcin Dalecki <martin@dalecki.de>
rschuster = Robert Schuster <robertschuster@fsfe.org>
lmillward = Lee Millward <lee.millward@gmail.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
mkuvyrkov = Maxim Kuvyrkov <mkuvyrkov@ispras.ru>
mueller = Dirk Mueller <dmueller@suse.com>
victork = Victor Kaplansky <victork@il.ibm.com>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
bdavis = Bud Davis <jmdavis@link.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
rth = Richard Henderson <rth@redhat.com>
jimb = Jim Blandy <jimb@red-bean.com>
jimb = Jim Blandy <jimb@codesourcery.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
tkoenig = Thomas Koenig <Thomas.Koenig@onlien.de>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
tkoenig = Thomas Koenig <Thomas.Koenig@online.de>
kargl = Steven G. Kargl <kargsl@comcast.net>
kargl = Steven G. Kargl <kargls@comcast.net>
abalkiss = Anthony Balkissoon <abalkiss@redhat.com>
bdavis = Bud Davis <bdavis9659@sbcglobal.net>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
rmh = Robert Millan <rmh@gcc.gnu.org>
danglin = John David Anglin <dave.anglin@nrc-crnc.gc.ca>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
danglin = John David Anglin <dava.anglin@nrc-cnrc.gc.ca>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
fche = Frank Ch. Eigler <fche@redhat.com>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
mueller = Dirk Mueller <dmueller@suse.de>
rearnsha = Richard Earnshaw <rearnsha@arm.com>
sandra = Sandra Loosemore <sandra@codesourcery.com>
shinwell = Mark Shinwell <shinwell@codesourcery.com>
schwab = Andreas Schwab <whitebox_@gmx.de>
schwab = Andreas Schwab <schwab@suse.de>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
rearnsha = Richard Earnshaw <richard.earnshaw@arm.com>
jwlemke = James Lemke <jwlemke@wasabisystems.com>
langton = Asher Langton <langton2@llnl.gov>
bothner = Per Bothner <bothner@bothner.com>
lauras = Laurynas Biveinis <laurynas.biveinis@gmail.com>
gary = Gary Benson <gbenson@redhat.com>
kargl = Steven G. Kargl <kargls@comcat.net>
steven = Steven Bosscher <steven@gcc.gnu.org>
rearnsha = Richard Earnshaw <rearnsha@arm.com>
pinskia = Andrew Pinski <pinskia@gmail.com>
kargl = Steven G. Kargl <kargls@comcast.net>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
danglin = John David Anglin <dave.anglin@nrc.ca>
pinskia = Andrew Pinski <pinskia@gmail.com>
gandalf = Andrew John Hughes <gnu_andrew@member.fsf.org>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
jwlemke = James Lemke <jim@lemke.org>
carlos = Carlos O'Donell <carlos@codesoucery.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
carlos = Carlos O'Donell <carlos@codesourcery.com>
pmj = Phillip Jordan <phillip.m.jordan@gmail.com>
bkoz = Benjamin Kosnik <bkoz@wells.artheist.org>
lmillward = Lee Millward <lee.millward@codesourcery.com>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
kargl = Steven G. Kargl <kargls@comcast.nt>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
pinskia = Andrew Pinski <pinksia@physics.uc.edu>
kgallowa = Kyle Galloway <kgallowa@redhat.com>
pinskia = Andrew Pinski <pinskia@physics.uc.edu>
kargl = Steven G. Kargl <kargls@comcast.net>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
robc = Roberto Costa <roberto.costa@st.com>
tbm = Martin Michlmayr <tbm@cyrius.com>
kargl = Steven G. Kargl <kargl@gcc.gnu.org>
aesok = Anatoly Sokolov <aesok@post.ru>
jsm28 = Joseph Myers <jsm@polyomino.org.uk>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
andreast = Andreas Tobler <a.tobler@schweiz.org>
chaoyingfu = Chao-ying Fu <fu@mips.com>
ths = Thiemo Seufer <ths@mips.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
jsm28 = Joseph Myers <joseph@codesourcery.com>
brooks = Brooks Moses <bmoses@stanford.edu>
pinskia = Andrew Pinski <pinskia@gmail.com>
liqin = Chen Liqin <liqin@sunnorth.com.cn>
burnus = Tobias Burnus <burnus@net-b.de>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
froydnj = Nathan Froyd <froydnj@codesourcery.com>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
pinskia = Andrew Pinski <pinskia@gmail.com>
vprus = Vladimir Prus <vladimir@codesourcery.com>
uros = Uros Bizjak <ubizjak@gmail.com>
smw = Stephen M. Webb <stephen.webb@bregmasoft.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
brooks = Brooks Moses <brooks.moses@codesourcery.com>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
davidu = David Ung <davidung@mips.com>
davidu = David Ung <davidu@mips.com>
pinskia = Andrew Pinski <Andrew_Pinski@playstation.sony.com>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
erven = Erven Rohou <erven.rohou@st.com>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
jvdelisle = Jerry DeLisle <jvdelisle@fcc.gnu.org>
pinskia = Andrew Pinski <pinskia@gmail.com>
andreao = Andrea Ornstein <andrea.ornstein@st.com>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
tsmigiel = Trevor Smigiel <trevor_smigiel@playstation.sony.com>
andreabo = Andrea Bona <andrea.bona@st.com>
jvdelisle = Jerry DeLisle <jvdelisle@gcc.gnu.org>
pthomas = Philipp Thomas <pth@suse.de>
pinskia = Andrew Pinski <pinskia@gmail.com>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
pinskia = Andrew Pinski <pinskia@gmail.com>
uros = Uros Bizjak <uros@kss-loka.si>
uros = Uros Bizjak <ubizjak@gmail.com>
baldrick = Duncan Sands <baldrick@free.fr>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
amacleod = Andrew Macleod <amacleod@redhat.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
pinskia = Andrew Pinski <pinskia@gmail.com>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
dfranke = Daniel Franke <franke.daniel@gmail.com>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
danglin = John David Anglin <dave.anglin.@nrc-cnrc.gc.ca>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
amylaar = Joern Rennecke <joern.rennecke@arc.com>
pinskia = Andrew Pinski <pinskia@gmail.com>
ian = Ian Lance Taylor <iant@google.com>
pinskia = Andrew Pinski <pinski@gmail.com>
simartin = Simon Martin <simartin@users.sourceforge.net>
megacz = Adam Megacz <megacz@cs.berkeley.edu>
pinskia = Andrew Pinski <pinskia@gmail.com>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
kargl = Steven G. Kargl <kargls@comcast.net>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
brobecke = Joel Brobecker <brobecker@adacore.com>
pinskia = Andrew Pinski <Andrew_Pinski@playstation.sony.com>
kargl = Steven G. Kargl <kargl@gcc.gnu.org>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
hjagasia = Harsha Jagasia <harsha.jagasia@amd.com>
olga = Olga Golovanevsky <olga@il.ibm.com>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc>
meissner = Michael Meissner <michael.meissner@amd.com>
bstarynk = Basile Starynkevitch <basile@starynkevitch.net>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
pinskia = Andrew Pinski <pinskia@gmail.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
kargl = Steven G. Kargl <kargl@gcc.gnu>
pinskia = Andrew Pinski <pinskia@gmail.com>
abel = Andrey Belevantsev <abel@ispras.ru>
spark = Seongbae Park <seongbae.park@gmail.com>
kargl = Steven G. Kargl <kargl@gcc.gnu.org>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
zippel = Roman Zippel <zippel@linux-m68k.org>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
echristo = Eric Christopher <echristo@gmail.com>
doko = Matthias Klose <doko@ubuntu.com>
echristo = Eric Christopher <echristo@apple.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
reichelt = Volker Reichelt <reichelt@netcologne.de>
doko = Matthias Klose <doko@debian.org>
doko = Matthias Klose <doko@ubuntu.com>
spop = Sebastian Pop <sebastian.pop@inria.fr>
zaks = Ayal Zaks <zaks@il.ibm.com>
revitale = Revital Eres <eres@il.ibm.com>
tkoenig = Thomas Koenig <tkoenig@gcc.gnu.org>
dwarak = Dwarakanath Rajagopal <dwarak.rajagopal@amd.com>
zack = Zack Weinberg <zack@mrtock.ucsd.edu>
davek = Dave Korn <dave.korn@artimi.com>
chrbr = Christian Bruel <christian.bruel@st.com>
doko = Matthias Klose <doko@debian.org>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
simonb = Simon Baldwin <simonb@google.com>
rsandifo = Richard Sandiford <richard@nildram.co.uk>
rsandifo = Richard Sandiford <richard@codesourcery.com>
bd3 = Benoit Dupont de Dinechin <benoit.dupont-de-dinechin@st.com>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
rus = Silvius Rus <rus@google.com>
tneumann = Thomas Neumann <tneumann@users.sourceforge.net>
robc = Roberto Costa <robsettantasei@gmail.com>
dnovillo = Diego Novillo <dnovillo@google.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
aesok = Anatoly Sokolov <aesok@dol.ru>
jwlemke = James Lemke <jwlemke@specifix.com>
rsandifo = Richard Sandiford <rsandifo@nildram.co.uk>
aaw = Ollie Wild <aaw@google.com>
rsandifo = Richard Sandiford <richard@codesourcery.com>
pinskia = Andrew Pinski <Andrew_pinski@playstation.sony.com>
hmchang = Hui-May Chang <hm.chang@apple.com>
echristo = Eric Christopher <echristo@gmail.com>
echristo = Eric Christopher <echristo@apple.com>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
doko = Matthias Klose <doko@ubuntu.com>
spop = Sebastian Pop <sebpop@gmail.com>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ths = Thiemo Seufer <ths@networkno.de>
rask = Rask Ingemann Lambertsen <rask@sygehus.dk>
cmatthews = Chris Matthews <chrismatthews@google.com>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
jsjodin = Jan Sjodin <jan.sjodin@amd.com>
rsandifo = Richard Sandiford <rsandifo@nildram.co.uk>
aesok = Anatoly Sokolov <aesok@post.ru>
rsandifo = Richard Sandiford <richard@codesourcery.com>
echristo = Eric Christopher <echristo@gmail.com>
echristo = Eric Christopher <echristo@apple.com>
rsandifo = Richard Sandiford <rsandifo@nildram.co.uk>
rsandifo = Richard Sandiford <richard@codesourcery.com>
zack = Zack Weinberg <zackw@panix.com>
aph = Andrew Haley <aph@hedges.billgatliff.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
aph = Andrew Haley <aph@redhat.com>
dsh = Dan Hipschman <dsh@google.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
lmillward = Lee Millward <lee.millward@gmail.com>
hubicka = Jan Hubicka <jH@suse.cz>
hubicka = Jan Hubicka <jh@suse.cz>
smw = Stephen M. Webb <stephenw@xandros.com>
rsandifo = Richard Sandiford <rsandifo@nildram.co.uk>
rsandifo = Richard Sandiford <richard@codesourcery.com>
pinskia = Andrew Pinski <pinskia@gmail.com>
rakdver = Zdenek Dvorak <ook@ucw.cz>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
reichelt = Volker Reichelt <v.reichelt@netcologne.de>
pinskia = Andrew Pinski <pinskia@gmail.com>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
pinskia = Andrew Pinski <pinskia@gmail.com>
mkuvyrkov = Maxim Kuvyrkov <maxim@codesourcery.com>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
pinskia = Andrew Pinski <pinskia@gmail.com>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
pinskia = Andrew Pinski <pinskia@gmail.com>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
bkoz = Benjamin Kosnik <bkoz@montsouris.artheist.org>
ktietz = Kai Tietz <kai.tietz@onevision.com>
bdavis = Bud Davis <jmdavis@link.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
zack = Zack Weinberg <zack@codesourcery.com>
pthaugen = Pat Haugen <pthaugen@us.ibm.com>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
doko = Matthias Klose <doko@debian.org>
rkidd = Robert Kidd <rkidd@crhc.uiuc.edu>
danglin = John David Anglin <dave.anglin@nrc-crnc.gc.ca>
rsandifo = Richard Sandiford <rsandifo@nildram.co.uk>
redi = Jonathan Wakely <jwakely.gcc@gmail.com>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
singler = Johannes Singler <singler@ira.uka.de>
dannysmith = Danny Smith <dannysmith@user.sourceforge.net>
hp = Hans-Peter Nilsson <hp@bitrange.com>
doko = Matthias Klose <doko@ubuntu.com>
spop = Sebastian Pop <sebastian.pop@amd.com>
hp = Hans-Peter Nilsson <hp@axis.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
bkoz = Benjamin Kosnik <bkoz@montsouris.artheist.org>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
dannysmith = Danny Smith <dannysmith@users.sourceforge.net>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
burnus = Tobias Burnus <burnus@gcc.gnu.org>
pinskia = Andrew Pinski <pinskia@gmail.com>
burnus = Tobias Burnus <burnus@net-b.de>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
davem = David S. Miller <davem@davemloft.net>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
devans = Doug Evans <dje@google.com>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
pinskia = Andrew Pinski <pinskia@gmail.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
dorit = Dorit Nuzman <doirit@il.ibm.com>
dougkwan = Doug Kwan <dougkwan@google.com>
sam = Samuel Tardieu <sam@rfc1149.net>
amonakov = Alexander Monakov <amonakov@ispras.ru>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
uweigand = Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
saliu = Sa Liu <saliu@de.ibm.com>
ths = Thiemo Seufer <ths@mips.com>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
hp = Hans-Peter Nilsson <hp@axis.com>
maddox = Bill Maddox <maddox@google.com>
meheff = Mark Heffernan <meheff@google.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
redi = Jonathan Wakely <jwakely-gcc@gmail.com>
redi = Jonathan Wakely <jwakely.gcc@gmail.com>
dorit = Dorit Nuzman <dorit@il.ibm.com>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
raksit = Raksit Ashok <raksit@google.com>
danglin = John David Anglin <dave.anglin.@nrc-cnrc.gc.ca>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
hjl = H.J. Lu <hjl.tools@gmail.com>
hjl = H.J. Lu <hongjiu.lu@intel.com>
grosser = Tobias Grosser <grosser@fim.uni-passau.de>
george = George Helffrich <george@gcc.gnu.org>
rwild = Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
tomby = Tomas Bily <tbily@suse.cz>
shebs = Stan Shebs <stanshebs@earthlink.net>
wilson = Jim Wilson <wilson@tuliptree.org>
aph = Andrew Haley <aph@littlepinkcloud.com>
espindola = Rafael Espindola <espindola@google.com>
victork = Victor Kaplansky <victork@gcc.gnu.org>
ebotcazou = Eric Botcazou <botcazou@adacore.com>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
victork = Victor Kaplansky <victork@il.ibm.com>
jamborm = Martin Jambor <mjambor@suse.cz>
pinskia = Andrew Pinski <pinskia@gmail.com>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
kuba = Jakub Staszak <kuba@et.pl>
pinskia = Andrew Pinski <pinskia@gmail.com>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
pinskia = Andrew Pinski <pinskia@gmail.com>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
pogma = Peter O'Gorman <pogma@thewrittenword.com>
ktietz = Kai Tietz <kai.tietz@onvision.com>
hutchinsonandy = Andy Hutchinson <hutchinsonandy@aim.com>
ktietz = Kai Tietz <kai.tietz@onevision.com>
olegr = Oleg Ryjkov <olegr@google.com>
pinskia = Andrew Pinski <pinskia@gmail.com>
aph = Andrew Haley <aph@redhat.com>
aph = Andrew Haley <aph@littlepinkcloud.com>
cgf = Christopher Faylor <me.gcc@gcc.gnu.org>
dannysmith = Danny Smith <dannysmith@users.net>
apop = Antoniu Pop <antoniu.pop@gmail.com>
dannysmith = Danny Smith <dannysmith@users.sourceforge.net>
pompa = Pompapathi V Gadad <Pompapathi.V.Gadad@nsc.com>
ktietz = Kai Tietz <kai.tietz@onvision.com>
ktietz = Kai Tietz <kai.tietz@onevision.com>
gsvelto = Gabriele Svelto <gabriele.svelto@st.com>
bdavis = Bud Davis <bdavis9659@sbcglobal.net>
kvanhees = Kris Van Hees <kris.van.hees@oracle.com>
pinskia = Andrew Pinski <Andrew.Pinski@playstation.sony.com>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
paolo = Paolo Carlini <paolo.carlini@oracle.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
janus = Janus Weil <janus@gcc.gnu.org>
davidxl = Xinliang David Li <davidxl@google.com>
aph = Andrew Haley <aph@redhat.com>
ktietz = Kai Tietz <kai.tietz@onevison.com>
ktietz = Kai Tietz <kai.tietz@onevision.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
domob = Daniel Kraft <d@domob.eu>
ericb = Eric Blake <ebb9@byu.net>
jye2 = Joey Ye <joey.ye@intel.com>
danglin = John David Anglin <dave.anglin@gcc-cnrc.gc.ca>
jwlemke = James Lemke <jwlemke@juniper.net>
andrewjenner = Andrew Jenner <andrew@codesourcery.com>
kristerw = Krister Walfridsson <krister.walfridsson@gmail.com>
xguo = Xuepeng Guo <xuepeng.guo@intel.com>
meissner = Michael Meissner <gnu@the-meissners.org>
pronesto = Fernando Pereira <fernando@cs.ucla.edu>
dodji = Dodji Seketeli <dseketel@redhat.com>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
dannysmith = Danny Smith <danyssmith@users.sourceforge.net>
dodji = Dodji Seketeli <dodji@redhat.com>
gingold = Tristan Gingold <gingold@adacore.com>
dannysmith = Danny Smith <dannysmith@usrs.sourceforge.net>
danglin = John David Anglin <dave.anglin@nrc.cnrc.gc.ca>
lcwu = Le-Chun Wu <lcwu@google.com>
tsmigiel = Trevor Smigiel <Trevor_Smigiel@playstation.sony.com>
rsandifo = Richard Sandiford <rdsandiford@goolemail.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
burnus = Tobias Burnus <burnus@net.b.de>
burnus = Tobias Burnus <burnus@net-b.de>
dannysmith = Danny Smith <dannysmith@users.sourceforge.net>
aldot = Bernhard Reutner-Fischer <aldot@gcc.gnu.org>
cfairles = Chris Fairles <cfairles@gcc.gnu.org>
daney = David Daney <david.daney@caviumnetworks.com>
burnus = Tobias Burnus <burnus@gcc.gnu.org>
bosch = Geert Bosch <bosch@adacore.com>
manu = Manuel López-Ibáñez <manu@gcc.gnu.org>
ccoutant = Cary Coutant <ccoutant@google.com>
meissner = Michael Meissner <meissner@linux.vnet.ibm.com>
burnus = Tobias Burnus <burnus@net-b.de>
clm = Catherine Moore <clm@codesourcery.com>
mikael = Mikael Morin <mikael.morin@tele2.fr>
baldrick = Duncan Sands <baldrick@gcc.gnu.org>
krebbel = Andreas Krebbel <Andreas.Krebbel@de.ibm.com>
jakub = Jakub Jelinek <jakuB@redhat.com>
jakub = Jakub Jelinek <jakub@redhat.com>
tschwinge = Thomas Schwinge <tschwinge@gnu.org>
ams = Andrew Stubbs <ams@codesourcery.com>
krebbel = Andreas Krebbel <krebbel1@de.ibm.com>
rsandifo = Richard Sandiford <rdsandiford@goolemail.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
hariharans = Hariharan Sandanagobalane <hariharan@picochip.com>
toon = Toon Moene <toon@moene.org>
davek = Dave Korn <dave.korn.cygwin@gmail.com>
pronesto = Fernando Pereira <pronesto@gmail.com>
liqin = Chen Liqin <liqin.chen@sunplusct.com>
luisgpm = Luis Machado <luisgpm@br.ibm.com>
daney = David Daney <ddaney@caviumnetworks.com>
pinskia = Andrew Pinski <andrew_pinskia@playstation.sony.com>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
pinskia = Andrew Pinski <pinskia@gmail.com>
pinskia = Andrew Pinski <pinski@gmail.com>
pinskia = Andrew Pinski <pinskia@gmail.com>
ayers = David Ayers <ayers@fsfe.org>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
kargl = Steven G. Kargl <sgk@troutmask.apl.washington.edu>
ramana = Ramana Radhakrishnan <ramana.r@gmail.com>
kargl = Steven G. Kargl <kargl@gcc.gnu.org>
meissner = Michael Meissner <gnu@the-meissners.org>
billingd = David Billinghurst <billingd@gcc.gnu.org>
dannysmith = Danny Smith <dannysmith@users.sourcforge.net>
meibf = Bingfeng Mei <bmei@broadcom.com>
dannysmith = Danny Smith <dannysmith@users.sourceforge.net>
eager = Michael Eager <eager@eagercon.com>
gandalf = Andrew John Hughes <ahughes@redhat.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>
krebbel = Andreas Krebbel <Andreas.Krebbel@de.ibm.com>
ramana = Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
nicola = Nicola Pero <nicola.pero@meta-innovation.com>
erven = Erven Rohou <erven.rohou@inria.fr>
kargl = Steven G. Kargl <kargls@comcast.net>
meissner = Michael Meissner <meissner@linux.vnet.ibm.com>
dfranke = Daniel Franke <frake.daniel@gmail.com>
dannysmith = Danny Smith <dannysmith@clear.net.nz>
pinskia = Andrew Pinski <pinskia@gmail.com>
krebbel = Andreas Krebbel <krebbel1@de.ibm.com>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
jingyu = Jing Yu <jingyu@google.com>
kargl = Steven G. Kargl <kargl@gcc.gnu.org>
tsmigiel = Trevor Smigiel <trevor_smigiel@playstation.sony.com>
wilson = Jim Wilson <wilson@codesourcery.com>
pinskia = Andrew Pinski <pinskia@gmail.com>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
tglek = Taras Glek <tglek@mozilla.com>
denisc = Denis Chertykov <chertykov@gmail.com>
tsmigiel = Trevor Smigiel <Trevor_Smigiel@playstation.sony.com>
denisc = Denis Chertykov <denisc@overta.ru>
rsandifo = Richard Sandiford <r.sandiford@uk.ibm.com>
gshobaki = Ghassan Shobaki <ghassan.shobaki@amd.com>
ian = Ian Lance Taylor <ian@airs.com>
ian = Ian Lance Taylor <iant@google.com>
green = Anthony Green <green@moxielogic.com>
kargl = Steven G. Kargl <kargls@comcast.net>
krebbel = Andreas Krebbel <Andreas.Krebbel@de.ibm.com>
ian = Ian Lance Taylor <ian@airs.com>
ian = Ian Lance Taylor <iant@google.com>
lifeng = Li Feng <nemokingdom@gmail.com>
krebbel = Andreas Krebbel <krebbel1@de.ibm.com>
denisc = Denis Chertykov <chertykov@gmail.com>
devans = Doug Evans <dje@sebabeach.org>
carrot = Wei Guozhi <carrot@google.com>
baldrick = Duncan Sands <baldrick@free.fr>
mark = Mark Wielaard <mjw@redhat.com>
kargl = Steven G. Kargl <kargl@gcc.gnu.org>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
dannysmith = Danny Smith <dansmister@gmail.com>
rsandifo = Richard Sandiford <r.sandiford@uk.ibm.com>
devans = Doug Evans <dje@google.com>
krebbel = Andreas Krebbel <Andreas.Krebbel@de.ibm.com>
rask = Rask Ingemann Lambertsen <ccc94453@vip.cybercity.dk>
krebbel = Andreas Krebbel <krebbel1@de.ibm.com>
pinskia = Andrew Pinski <pinskia@gmail.com>
nvachhar = Neil Vachharajani <nvachhar@gmail.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
macro = Maciej W. Rozycki <macro@codesourcery.com>
cgd = Chris Demetriou <cgd@google.com>
ro = Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
dgutson = Daniel Gutson <dgutson@codesourcery.com>
krebbel = Andreas Krebbel <Andreas.Krebbel@de.ibm.com>
amylaar = Joern Rennecke <joern.rennecke@embecosm.com>
pinskia = Andrew Pinski <pinskia@gcc.gnu.org>
nvachhar = Neil Vachharajani <nvachhar@google.com>
schwab = Andreas Schwab <schwab@redhat.com>
revitale = Revital Eres <ERES@il.ibm.com>
gfunck = Gary Funck <gary@intrepid.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
gdr = Gabriel Dos Reis <gdr@cs.tamu.edu>
gdr = Gabriel Dos Reis <gdr@cse.tamu.edu>
rus = Silvius Rus <silvius.rus@gmail.com>
pmuldoon = Phil Muldoon <pmuldoon@redhat.com>
dannysmith = Danny Smith <dannysmith@users.sourceforge.net>
gdr = Gabriel Dos Reis <gdr@cs.tamu.edu>
emsr = Edward Smith-Rowland <3dw4rd@verizon.net>
hutchinsonandy = Andy Hutchinson <hutchinsonandy@gcc.gnu.org>
singler = Johannes Singler <singler@kit.edu>
pinskia = Andrew Pinski <pinskia@gcc.gnu.org>
uweigand = Ulrich Weigand <uweigand@de.ibm.com>
revitale = Revital Eres <eres@il.ibm.com>
uweigand = Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
macro = Maciej W. Rozycki <macro@linux-mips.org>
pinskia = Andrew Pinski <andrew_pinski@playstation.sony.com>
amylaar = Joern Rennecke <amylaar@spamcop.net>
jbeniston = Jon Beniston <jon@beniston.com>
jkratoch = Jan Kratochvil <jan.kratochvil@redhat.com>
nemet = Adam Nemet <adambnemet@gmail.com>
nemet = Adam Nemet <adambnmet@gmail.com>
spop = Sebastian Pop <sebpop@gmail.com>
spop = Sebastian Pop <sebastian.pop@amd.com>
ktietz = Kai Tietz <Kai.Tietz@onevision.com>
tglek = Taras Glek <taras@mozilla.com>
dfranke = Daniel Franke <franke.daniel@gmail.com>
pzhao = Shujing Zhao <pearly.zhao@oracle.com>
spop = Sebastian Pop <sebpop@gmail.com>
bryce = Bryce McKinlay <bmckinlay@gmail.com>
spop = Sebastian Pop <sebastian.pop@amd.com>
spop = Sebastian Pop <sebpop@gmail.com>
spop = Sebastian Pop <sebastian.pop@amd.com>
spop = Sebastian Pop <sebpop@gmail.com>
cgf = Christopher Faylor <cgf@gcc.gnu.org>
green = Anthony Green <green@redhat.com>
green = Anthony Green <green@moxielogic.com>
spop = Sebastian Pop <sebastian.pop@amd.com>
rus = Silvius Rus <rus@google.com>
andreast = Andreas Tobler <andreast@fgznet.ch>
trifunovic = Konrad Trifunovic <konrad.trifunovic@inria.fr>
tlafage = Thierry Lafage <thierry.lafage@inria.fr>
rsandifo = Richard Sandiford <r.sandiford@uk.ibm.com>
eweddington = Eric Weddington <eric.weddington@atmel.com>
amylaar = Joern Rennecke <joern.rennecke@embecosm.com>
ktietz = Kai Tietz <kai.tietz@onevision.com>
pinskia = Andrew Pinski <pinskia@gmail.com>
mrs = Mike Stump <mikestump@comcast.net>
bje = Ben Elliston <bje@gnu.org>
amodra = Alan Modra <amodra@gmail.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
pinskia = Andrew Pinski <andrew_pinski@caviumnetworks.com>
jiez = Jie Zhang <jie@codesourcery.com>
bernds = Bernd Schmidt <bernds@codesourcery.com>
bernds = Bernd Schmidt <bernd.schmidt@analog.com>
bernds = Bernd Schmidt <bernd.schmidt@codesourcery.com>
pinskia = Andrew Pinski <pinskia@gmail.com>
uweigand = Ulrich Weigand <uweigand@de.ibm.com>
hubicka = Jan Hubicka <jh@suse.czpli>
iains = Iain Sandoe <iains@gcc.gnu.org>
hubicka = Jan Hubicka <jh@suse.cz>
kwilliam = Kevin Williams <kevin.williams@inria.fr>
bernds = Bernd Schmidt <bernds@codesourcery.com>
davidxl = Xinliang David Li <davidxl@gcc.gnu.org>
hp = Hans-Peter Nilsson <hp@axis.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
davidxl = Xinliang David Li <davidxl@google.com>
burnus = Tobias Burnus <Mburnus@net-b.de>
burnus = Tobias Burnus <burnus@net-b.de>
pinskia = Andrew Pinski <andrew.pinski@caviumnetworks.com>
tmsriram = Sriraman Tallam <tmsriram@google.com>
froydnj = Nathan Froyd <froydnj@cs.rice.edu>
froydnj = Nathan Froyd <froydnj@codesourcery.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
hp = Hans-Peter Nilsson <hp@axis.com>
sterling = Sterling Augustine <sterling@tensilica.com>
uweigand = Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
fabien = Fabien Chêne <fabien@gcc.gnu.org>
amylaar = Joern Rennecke <amylaar@spamcop.net>
pogma = Peter O'Gorman <peter@pogma.com>
amylaar = Joern Rennecke <joern.rennecke@embecosm.com>
smw = Stephen M. Webb <stephen.webb@bregmasoft.ca>
mikael = Mikael Morin <mikael@gcc.gnu.org>
redfire = Jeremie Salvucci <jeremie.salvucci@free.fr>
rsandifo = Richard Sandiford <r.sandiford@uk.ibm.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
jyasskin = Jeffrey Yasskin <jyasskin@google.com>
cltang = Chung-Lin Tang <cltang@codesourcery.com>
ak = Andi Kleen <ak@linux.intel.com>
dyuste = David Yuste <david.yuste@gmail.com>
cfang = Changpeng Fang <changpeng.fang@amd.com>
green = Anthony Green <green@redhat.com>
qiyao = Yao Qi <yao@codesourcery.com>
spop = Sebastian Pop <sebastian.pop@inria.fr>
spop = Sebastian Pop <sebastian.pop@amd.com>
xmj = Mingjie Xing <mingjie.xing@gmail.com>
macro = Maciej W. Rozycki <macro@codesourcery.com>
ibolton = Ian Bolton <ian.bolton@arm.com>
mshawcroft = Marcus Shawcroft <marcus.shawcroft@arm.com>
schwab = Andreas Schwab <schwab@redhat.com>
hjl = H.J. Lu <hjl.tools@gmail.com>
nicola = Nicola Pero <nicola@nicola.brainstorm.co.uk>
nicola = Nicola Pero <nicola.pero@meta-innovation.com>
hjl = H.J. Lu <hongjiu.lu@intel.com>
belagod = Tejas Belagod <tejas.belagod@arm.com>
nicola = Nicola Pero <nicola@nicola.brainstorm.co.uk>
nicola = Nicola Pero <nicola.pero@meta-innovation.com>
green = Anthony Green <green@moxielogic.com>
tschwinge = Thomas Schwinge <thomas@schwinge.name>
nicola = Nicola Pero <nicola@nicola.brainstorm.co.uk>
nicola = Nicola Pero <nicola.pero@meta-innovation.com>
pkoning = Paul Koning <ni1d@arrl.net>
wilson = Jim Wilson <wilson@tuliptree.org>
pkoning = Paul Koning <pkoning@equallogic.com>
pkoning = Paul Koning <ni1d@arrl.net>
amylaar = Joern Rennecke <amylaar@spamcop.net>
bdavis = Bud Davis <jimmied@smu.edu>
schwab = Andreas Schwab <schwab@linux-m68k.org>
fdumont = François Dumont <francois.cppdevs@free.fr>
ghazi = Kaveh Ghazi <ghazi@gcc.gnu.org>
schwab = Andreas Schwab <schwab@redhat.com>
burnus = Tobias Burnus <burnus@net.b.de>
schwab = Andreas Schwab <schwab@linux-m68k.org>
burnus = Tobias Burnus <burnus@net-b.de>
qneill = Quentin Neill <quentin.neill.gnu@gmail.com>
bdavis = Bud Davis <jmdavis@link.com>
schwab = Andreas Schwab <schwab@redhat.com>
asharif = Ahmad Sharif <asharif@google.com>
kaushikp = Kaushik Phatak <kaushik.phatak@kpitcummins.com>
mikael = Mikael Morin <mikael.morin@gcc.gnu.org>
mikael = Mikael Morin <mikael@gcc.gnu.org>
schwab = Andreas Schwab <schwab@linux-m68k.org>
nicola = Nicola Pero <nicola@nicola.brainstorm.co.uk>
nicola = Nicola Pero <nicola.pero@meta-innovation.com>
nicola = Nicola Pero <nicola@nicola.brainstorm.co.uk>
nicola = Nicola Pero <nicola.pero@meta-innovation.com>
wschmidt = William Schmidt <wschmidt@linux.vnet.ibm.com>
jakub = Jakub Jelinek <jj@ultra.linux.cz>
jakub = Jakub Jelinek <jakub@redhat.com>
vapier = Mike Frysinger <vapier@gentoo.org>
schwab = Andreas Schwab <schwab@redhat.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>
lekernel = Sebastien Bourdeauducq <sebastien@milkymist.org>
mikael = Mikael Morin <mikael.morin@sfr.fr>
mikael = Mikael Morin <mikael@gcc.gnu.org>
ktietz = Kai Tietz <ktietz@redhat.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
jye2 = Joey Ye <joey.ye@arm.com>
xguo = Xuepeng Guo <terry.guo@arm.com>
liqin = Chen Liqin <liqin.gcc@gmail.com>
ramana = Ramana Radhakrishnan <ramana.radhakrishnan@linaro.org>
irar = Ira Rosen <ira.rosen@linaro.org>
bonzini = Paolo Bonzini <pbonzini@redhat.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
redi = Jonathan Wakely <redi@gcc.gnu.org>
vries = Tom de Vries <tom@codesourcery.com>
sterling = Sterling Augustine <augustine.sterling@gmail.com>
redi = Jonathan Wakely <jwakely.gcc@gmail.com>
shenders = Stuart Henderson <shenders@gcc.gnu.org>
yufeng = Yufeng Zhang <yufeng.zhang@arm.com>
gjl = Georg-Johann Lay <avr@gjlay.de>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
meyering = Jim Meyering <meyering@redhat.com>
revitale = Revital Eres <revital.eres@linaro.org>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
eraman = Easwaran Raman <eraman@google.com>
jiez = Jie Zhang <jzhang918@gmail.com>
danglin = John David Anglin <dave.anglin@nrc-cnrc.ca>
gdr = Gabriel Dos Reis <gdr@integrable-solutions.net>
crowl = Lawrence Crowl <crowl@google.com>
amylaar = Joern Rennecke <joern.rennecke@embecosm.com>
janis = Janis Johnson <janisjo@codesourcery.com>
ppluzhnikov = Paul Pluzhnikov <ppluzhnikov@google.com>
schwab = Andreas Schwab <schwab@redhat.com>
martinthuresson = Martin Thuresson <martint@google.com>
amylaar = Joern Rennecke <amylaar@spamcop.net>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
qneill = Quentin Neill <quentin.neill@amd.com>
pinskia = Andrew Pinski <pinskia@gmail.com>
amylaar = Joern Rennecke <joern.rennecke@embecosm.com>
drow = Daniel Jacobowitz <drow@false.org>
pbrook = Paul Brook <paul@cpodesourcery.com>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
nenadv = Nenad Vukicevic <nenad@intrepid.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
pogma = Peter O'Gorman <pogma@thewrittenword.com>
hp = Hans-Peter Nilsson <hp@axis.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
gchare = Gabriel Charette <gchare@google.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
mikael = Mikael Morin <mikael.morin@sfr.fr>
doko = Matthias Klose <doko@debian.org>
dcarrera = Daniel Carrera <dcarrera@gmail.com>
doko = Matthias Klose <doko@ubuntu.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
schwab = Andreas Schwab <schwab@linux-m68k.org>
pinskia = Andrew Pinski <apinski@cavium.com>
bonzini = Paolo Bonzini <bonzini@gnu.org>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
schwab = Andreas Schwab <schwab@redhat.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
doko = Matthias Klose <doko@debian.org>
mikael = Mikael Morin <mikael.morin@gcc.gnu.org>
ramana = Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
mikael = Mikael Morin <mikael.morin@sfr.fr>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
pbrook = Paul Brook <paul@codesourcery.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
fdumont = François Dumont <fdumont@gcc.gnu.org>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
jbeulich = Jan Beulich <jbeulich@suse.com>
ramana = Ramana Radhakrishnan <ramana.radhakrishnan@linaro.org>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
tema = Artjoms Sinkarovs <artyom.shinkaroff@gmail.com>
uweigand = Ulrich Weigand <ulrich.weigand@linaro.org>
mikael = Mikael Morin <mikael@gcc.gnu.org>
doko = Matthias Klose <doko@ubuntu.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
uweigand = Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
dehao = Dehao Chen <dehao@google.com>
kargl = Steven G. Kargl <kargl@gcc.gcu.org>
kargl = Steven G. Kargl <kargl@gcc.gnu.org>
tejohnson = Teresa Johnson <tejohnson@google.com>
kyukhin = Kirill Yukhin <kirill.yukhin@intel.com>
nathan = Nathan Sidwell <nathan@acm.org>
fxcoudert = François-Xavier Coudert <fxcoudert@gcc.gnu.org>
torvald = Torvald Riegel <triegel@redhat.com>
liujiangning = Jiangning Liu <jiangning.liu@arm.com>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
sameerad = Sameera Deshpande <sameera.deshpande@arm.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
mgretton = Matthew Gretton-Dann <matthew.gretton-dann@arm.com>
meissner = Michael Meissner <meissner@the-meissners.org>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
dvyukov = Dmitry Vyukov <dvyukov@google.com>
hariharans = Hariharan Sandanagobalane <hariharan.gcc@gmail.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>
meissner = Michael Meissner <meissner@linux.vnet.ibm.com>
irar = Ira Rosen <irar@il.ibm.com>
olegendo = Oleg Endo <olegendo@gcc.gnu.org>
hubicka = Jan Hubicka <jhjh@suse.cz>
bviyer = Balaji V. Iyer <bviyer@gmail.com>
hubicka = Jan Hubicka <jh@suse.cz>
shenhan = Han Shen <shenhan@google.com>
jwlemke = James Lemke <jwlemke@codesourcery.com>
harshit = Harshit Chopra <harshit@google.com>
jayants = Jayant Sonar <jayant.sonar@kpitcummins.com>
vekumar = Venkataramanan Kumar <venkataramanan.kumar@amd.com>
amker = Bin Cheng <bin.cheng@arm.com>
walt = Walter Lee <walt@tilera.com>
pmarlier = Patrick Marlier <patrick.marlier@gmail.com>
uweigand = Ulrich Weigand <ulrich.weigand@linaro.org>
uweigand = Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
uweigand = Ulrich Weigand <ulrich.weigand@linaro.org>
meissner = Michael Meissner <meissner@the-meissners.org>
sje = Steve Ellcey <sellcey@mips.com>
meissner = Michael Meissner <meissner@linux.vnet.ibm.com>
tschwinge = Thomas Schwinge <thomas@codesourcery.com>
naveenh = Naveen H.S <naveen.S@kpitcummins.com>
michaelh = Michael Hope <michael.hope@linaro.org>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
gretay = Greta Yorsh <Greta.Yorsh@arm.com>
gretay = Greta Yorsh <greta.yorsh@arm.com>
rsandifo = Richard Sandiford <r.sandiford@uk.ibm.com>
gretay = Greta Yorsh <Greta.Yorsh@arm.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
glisse = Marc Glisse <marc.glisse@inria.fr>
rsandifo = Richard Sandiford <r.sandiford@uk.ibm.com>
edmarwjr = Edmar Wienskoski <edmar@freescale.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
sterling = Sterling Augustine <saugustine@google.com>
rsandifo = Richard Sandiford <r.sandiford@uk.ibm.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
janis = Janis Johnson <janosjo@codesourcery.com>
gretay = Greta Yorsh <greta.yorsh@arm.com>
gretay = Greta Yorsh <Greta.Yorsh@arm.com>
meadori = Meador Inge <meadori@codesourcery.com>
iains = Iain Sandoe <iain@codesourcery.com>
fw = Florian Weimer <fweimer@redhat.com>
janis = Janis Johnson <janisjo@codesourcery.com>
uweigand = Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
sandra = Sandra Loosemore <sandra@codesroucery.com>
uweigand = Ulrich Weigand <ulrich.weigand@linaro.org>
jbglaw = Jan-Benedict Glaw <jbglaw@lug-owl.de>
sandra = Sandra Loosemore <sandra@codesourcery.com>
wilson = Jim Wilson <jimwilso@cisco.com>
froydnj = Nathan Froyd <froydnj@gcc.gnu.org>
uweigand = Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
pinskia = Andrew Pinski <pinskia@gmail.com>
pinskia = Andrew Pinski <apinski@cavium.com>
drepper = Ulrich Drepper <drepper@gmail.com>
ramana = Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
clyon = Christophe Lyon <christophe.lyon@linaro.org>
clyon = Christophe Lyon <christophe.lyon@st.com>
clyon = Christophe Lyon <christophe.lyon@linaro.org>
hp = Hans-Peter Nilsson <hp@bitrange.com>
uweigand = Ulrich Weigand <ulrich.weigand@linaro.org>
hp = Hans-Peter Nilsson <hp@axis.com>
mpolacek = Marek Polacek <polacek@redhat.com>
singhai = Sharad Singhai <singhai@google.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
hp = Hans-Peter Nilsson <hp@axis.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
uweigand = Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
echristo = Eric Christopher <echristo@gmail.com>
jgreenhalgh = James Greenhalgh <james.greenhalgh@arm.com>
gganesh = Ganesh Gopalasubramanian <Ganesh.Gopalasubramanian@amd.com>
rsandifo = Richard Sandiford <r.sandiford@uk.ibm.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
hjl = H.J. Lu <hjl.tools@gmail.com>
hjl = H.J. Lu <hongjiu.lu@intel.com>
hp = Hans-Peter Nilsson <hp@axis.com>
uweigand = Ulrich Weigand <ulrich.weigand@linaro.org>
roland = Roland McGrath <roland@hack.frob.com>
kcc = Kostya Serebryany <kcc@google.com>
wmi = Wei Mi <wmi@google.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
bonzini = Paolo Bonzini <pbonzini@redhat.com>
mgretton = Matthew Gretton-Dann <matthew.gretton-dann@linaro.org>
ktkachov = Kyrylo Tkachov <kyrylo.tkachov@arm.com>
sofiane = Sofiane Naci <sofiane.naci@arm.com>
mkuvyrkov = Maxim Kuvyrkov <maxim.kuvyrkov@gmail.com>
schwab = Andreas Schwab <schwab@suse.de>
naveenh = Naveen H.S <Naveen.Hurugalawadi@caviumnetworks.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>
hp = Hans-Peter Nilsson <hp@axis.com>
mkuvyrkov = Maxim Kuvyrkov <maxim@kugelworks.com>
schwab = Andreas Schwab <schwab@suse.de>
danglin = John David Anglin <dave.anglin@nrc-cnrc.ca>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
asutton = Andrew Sutton <andrew.n.sutton@gmail.com>
gandalf = Andrew John Hughes <gnu.andrew@redhat.com>
ak = Andi Kleen <andi@my.domain.org>
tiloschwarz = Tilo Schwarz <tilo@tilo-schwarz.de>
roland = Roland McGrath <mcgrathr@google.com>
uweigand = Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
ak = Andi Kleen <ak@linux.intel.com>
jasonwucj = Chung-Ju Wu <jasonwucj@gmail.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>
jgreenhalgh = James Greenhalgh <jame.greenhalgh@arm.com>
jgreenhalgh = James Greenhalgh <james.greenhalgh@arm.com>
ebotcazou = Eric Botcazou <ebotcazou@gcc.gnu.org>
rsandifo = Richard Sandiford <rsandifo@linux.vnet.ibm.com>
brooks = Brooks Moses <bmoses@google.com>
grahams = Graham Stott <grahams@btinternet.com>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
schwab = Andreas Schwab <schwab@suse.de>
nathan = Nathan Sidwell <nathan@codesourcery.com>
sje = Steve Ellcey <sellcey@imgtec.com>
dmalcolm = David Malcolm <dmalcolm@redhat.com>
rsandifo = Richard Sandiford <rsandifo@linux.vnet.ibm.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
bviyer = Balaji V. Iyer <balaji.v.iyer@intel.com>
sje = Steve Ellcey <sellcey@mips.com>
sje = Steve Ellcey <sellcey@imgtec.com>
dinar = Dinar Temirbulatov <dinar@kugelworks.com>
vp = Vidya Praveen <vidyapraveen@arm.com>
sje = Steve Ellcey <sellcey@mips.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
grahams = Graham Stott <graham.stott@btinternet.com>
grosser = Tobias Grosser <tobias@grosser.es>
congh = Cong Hou <congh@google.com>
timshen = Tim Shen <timshen91@gmail.com>
yroux = Yvan Roux <yvan.roux@linaro.org>
jbglaw = Jan-Benedict Glaw <jbglaw@owl.de>
jbglaw = Jan-Benedict Glaw <jbglaw@lug-owl.de>
ctice = Caroline Tice <cmtice@google.com>
bkoz = Benjamin Kosnik <bkoz@rehat.com>
bkoz = Benjamin Kosnik <bkoz@redhat.com>
carlos = Carlos O'Donell <carlos@redhat.com>
abutcher = Adam Butcher <adam@jessamine.co.uk>
hubicka = Jan Hubicka <jh@susue.cz>
hubicka = Jan Hubicka <jh@suse.cz>
gdr = Gabriel Dos Reis <gdre@integrable-solutions.net>
gdr = Gabriel Dos Reis <gdr@integrable-solutions.net>
edlinger = Bernd Edlinger <bernd.edlinger@hotmail.de>
danglin = John David Anglin <danglin@gcc.gnu.org>
schwab = Andreas Schwab <schwab@linux-m68k.org>
schwab = Andreas Schwab <schwab@suse.de>
jayants = Jayant Sonar <rsonar.jayant@gmail.com>
fw = Florian Weimer <fw@deneb.enyo.de>
pmatos = Paulo Matos <pmatos@broadcom.com>
vekumar = Venkataramanan Kumar <venkataramanan.kumar@linaro.org>
xur = Rong Xu <xur@google.com>
hp = Hans-Peter Nilsson <hp@axis.com>
rth = Richard Henderson <rth@twiddle.net>
zqchen = Zhenqiang Chen <zhenqiang.chen@linaro.org>
ygribov = Yury Gribov <y.gribov@samsung.com>
tbsaunde = Trevor Saunders <tsaunders@mozilla.com>
marxin = Martin Liska <marxin.liska@gmail.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>
hubicka = Jan Hubicka <hubicka@ucw.cz>
schwab = Andreas Schwab <schwab@suse.de>
zqchen = Zhenqiang Chen <zhenqiang.chen@arm.com>
ktietz = Kai Tietz <kitetz@redhat.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>
hubicka = Jan Hubicka <jh@suse.cz>
trippels = Markus Trippelsdorf <markus@trippelsdorf.de>
jvdelisle = Jerry DeLisle <jvdelisle@gcc.gnu>
hubicka = Jan Hubicka <hubicka@ucw.cz>
andreast = Andreas Tobler <andreast@gcc.gnu.org>
redi = Jonathan Wakely <jwakely@redhat.com>
hubicka = Jan Hubicka <jh@suse.cz>
rsandifo = Richard Sandiford <rsandifo@linux.vnet.ibm.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
rth = Richard Henderson <rth@redhat.com>
tudalova = Tatiana Udalova <t.udalova@samsung.com>
dodji = Dodji Seketeli <dodji@seketeli.org>
chefmax = Maxim Ostapenko <m.ostapenko@partner.samsung.com>
hubicka = Jan Hubicka <hubicka@ucw.cz>
hubicka = Jan Hubicka <jh@suse.cz>
hubicka = Jan Hubicka <hubicka@ucw.cz>
rth = Richard Henderson <rth@twiddle.net>
hubicka = Jan Hubicka <jh@suse.cz>
hubicka = Jan Hubicka <hubicka@ucw.cz>
hubicka = Jan Hubicka <jh@suse.cz>
hubicka = Jan Hubicka <hubicka@ucw.cz>
rth = Richard Henderson <rth@redhat.com>
rsandifo = Richard Sandiford <rsandifo@linux.vnet.ibm.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
kugan = Kugan Vivekanandarajah <kuganv@linaro.org>
ktietz = Kai Tietz <ktietz@redhat.com>
schwab = Andreas Schwab <schwab@suse.de>
hubicka = Jan Hubicka <jh@suse.cz>
hubicka = Jan Hubicka <hubicka@ucw.cz>
pmatos = Paulo Matos <paulo@matos-sorge.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>
zqchen = Zhenqiang Chen <zhenqiang.chen@linaro.org>
rth = Richard Henderson <rth@twiddle.net>
jvdelisle = Jerry DeLisle <jvdelisle@gcc.gnu.org>
jvdelisle = Jerry DeLisle <jvdelisle@gcc.gnu>
schwab = Andreas Schwab <schwab@suse.de>
dominiq = Dominique d'Humieres <dominiq@lps.ens.fr>
rth = Richard Henderson <rth@redhat.com>
jsm28 = Joseph Myers <joseph@codesourcery.cmo>
schwab = Andreas Schwab <schwab@linux-m68k.org>
hubicka = Jan Hubicka <hubcika@ucw.cz>
schwab = Andreas Schwab <schwab@suse.de>
hubicka = Jan Hubicka <hubicka@ucw.cz>
ian = Ian Lance Taylor <iant@golang.org>
hubicka = Jan Hubicka <jh@suse.cz>
hubicka = Jan Hubicka <hubicka@ucw.cz>
schwab = Andreas Schwab <schwab@linux-m68k.org>
dinar = Dinar Temirbulatov <dtemirbulatov@gmail.com>
schwab = Andreas Schwab <schwab@suse.de>
alalaw01 = Alan Lawrence <alan.lawrence@arm.com>
ian = Ian Lance Taylor <iant@google.com>
jsm28 = Joseph Myers <joseph@codesourcery.com>
rsandifo = Richard Sandiford <rsandifo@linux.vnet.ibm.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>
rsandifo = Richard Sandiford <r.sandiford@uk.ibm.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
cbaylis = Charles Baylis <charles.baylis@linaro.org>
rsandifo = Richard Sandiford <rsandifo@linux.vnet.ibm.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
fw = Florian Weimer <fweimer@redhat.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
clm = Catherine Moore <clm@cm00re.com>
rsandifo = Richard Sandiford <r.sandiford@uk.ibm.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
schwab = Andreas Schwab <schwab@suse.de>
merzlyakovao = Alexey Merzlyakov <alexey.merzlyakov@samsung.com>
rsandifo = Richard Sandiford <r.sandiford@uk.ibm.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
rsandifo = Richard Sandiford <r.sandiford@uk.ibm.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
rsandifo = Richard Sandiford <rsandifo@linux.vnet.ibm.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
rsandifo = Richard Sandiford <rsandifo@linux.vnet.ibm.com>
mkuvyrkov = Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>
hp = Hans-Peter Nilsson <hp@axis.com>
thopre01 = Thomas Preud'homme <thomas.preudhomme@arm.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
jvdelisle = Jerry DeLisle <jvdelisle@gcc.gnu.org>
rsandifo = Richard Sandiford <r.sandiford@uk.ibm.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
kaushikp = Kaushik Phatak <kaushik.phatak@kpit.com>
palves = Pedro Alves <palves@redhat.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>
schwab = Andreas Schwab <schwab@suse.de>
schwab = Andreas Schwab <schwab@linux-m68k.org>
abennett = Andrew Bennett <andrew.bennett@imgtec.com>
marxin = Martin Liska <mliska@suse.cz>
schwab = Andreas Schwab <schwab@suse.de>
spop = Sebastian Pop <sebpop@gmail.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
mpf = Matthew Fortune <matthew.fortune@imgtec.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>
romangareev = Roman Gareev <gareevroman@gmail.com>
timshen = Tim Shen <timshen@google.com>
dodji = Dodji Seketeli <dodji@redhat.com>
mzakirov = Marat Zakirov <m.zakirov@samsung.com>
azanella = Adhemerval Zanella <azanella@linux.vnet.ibm.com>
hp = Hans-Peter Nilsson <hp@axis.com>
nathan = Nathan Sidwell <nathan@acm.org>
schwab = Andreas Schwab <schwab@suse.de>
jnorris = James Norris <jnorris@codesourcery.com>
jiwang = Jiong Wang <jiong.wang@arm.com>
zqchen = Zhenqiang Chen <zhenqiang.chen@arm.com>
ahyangyi2 = Yi Yang <ahyangyi@google.com>
mircea = Mircea Namolaru <mircea.namolaru@inria.fr>
sylvestre = Sylvestre Ledru <sylvestre@debian.org>
tocarip = Ilya Tocar <tocarip@gmail.com>
iverbin = Ilya Verbin <iverbin@gmail.com>
ppalka = Patrick Palka <ppalka@gcc.gnu.org>
cgf = Christopher Faylor <me.gnu@cgf.cx>
vondele = Joost VandeVondele <vondele@gcc.gnu.org>
vondele = Joost VandeVondele <Joost.VandeVondele@mat.ethz.ch>
spop = Sebastian Pop <s.pop@samsung.com>
rsandifo = Richard Sandiford <richard.sandiford@arm.com>
tocarip = Ilya Tocar <ilya.tocar@intel.com>
rsandifo = Richard Sandiford <rdsandiford@googlemail.com>
vondele = Joost VandeVondele <vondele@gcc.gnu.org>
rsandifo = Richard Sandiford <richard.sandiford@arm.com>
clm = Catherine Moore <clm@codesourcery.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>
fyang = Fei Yang <felix.yang@huawei.com>
danglin = John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
jcmvbkbc = Max Filippov <jcmvbkbc@gmail.com>
schwab = Andreas Schwab <schwab@suse.de>
danglin = John David Anglin <danglin@gcc.gnu.org>
schwab = Andreas Schwab <schwab@linux-m68k.org>
iverbin = Ilya Verbin <ilya.verbin@intel.com>
schwab = Andreas Schwab <schwab@suse.de>
mkuvyrkov = Maxim Kuvyrkov <maxim.kuvyrkov@gmail.com>
danielh = Daniel Hellstrom <daniel@gaisler.com>
hp = Hans-Peter Nilsson <hp@dummer.localdomain>
hp = Hans-Peter Nilsson <hp@axis.com>
rupp = Douglas Rupp <douglas.b.rupp@gmail.com>
sje = Steve Ellcey <sellcey@imgtec.com>
ienkovich = Ilya Enkovich <ilya.enkovich@intel.com>
prachigodbole = Prachi Godbole <prachi.godbole@imgtec.com>
halewang = Hale Wang <Hale.Wang@arm.com>
halewang = Hale Wang <hale.wang@arm.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>
zqchen = Zhenqiang Chen <zhenqiang.chen@linaor.org>
zqchen = Zhenqiang Chen <zhenqiang.chen@linaro.org>
zqchen = Zhenqiang Chen <zhenqiang.chen@arm.com>
schwab = Andreas Schwab <schwab@suse.de>
avelenko = Alex Velenko <Alex.Velenko@arm.com>
renlin = Renlin Li <Renlin.Li@arm.com>
mkuvyrkov = Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>
zqchen = Zhenqiang Chen <zhenqiang.chen@linaro.org>
renlin = Renlin Li <renlin.li@arm.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>
boger = Lynn Boger <laboger@linux.vnet.ibm.com>
zqchen = Zhenqiang Chen <zhenqiang.chen@arm.com>
haubi = Michael Haubenwallner <michael.haubenwallner@ssi-schaefer.com>
pmderodat = Pierre-Marie de Rodat <derodat@adacore.com>
prathamesh3492 = Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org>
sh = Sebastian Huber <sebastian.huber@embedded-brains.de>
sje = Steve Ellcey <sellcey@mips.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
hp = Hans-Peter Nilsson <hp@axis.com>
ptomsich = Philipp Tomsich <ptomsich@theobroma-systems.com>
ptomsich = Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
ptomsich = Philipp Tomsich <ptomsich@theobroma-systems.com>
ptomsich = Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
uecker = Martin Uecker <uecker@eecs.berkeley.edu>
vehre = Andre Vehreschild <vehre@gmx.de>
tkoenig = Thomas Koenig <tkoenig@netcologne.de>
blzut3 = Braden Obrzut <admin@maniacsvault.net>
rts = Robert Suchanek <robert.suchanek@imgtec.com>
janis = Janis Johnson <janis.marie.johnson@gmail.com>
mwahab = Matthew Wahab <matthew.wahab@arm.com>
danglin = John David Anglin <danlgin@gcc.gnu.org>
msebor = Martin Sebor <msebor@redhat.com>
sje = Steve Ellcey <sellcey@imgtec.com>
amylaar = Joern Rennecke <gnu@amylaar.uk>
krebbel = Andreas Krebbel <krebbel@linux.vnet.ibm.com>
avelenko = Alex Velenko <alex.velenko@arm.com>
danglin = John David Anglin <danglin@gcc.gnu.org>
tkoenig = Thomas Koenig <tkoenig@gcc.gnu.org>
avelenko = Alex Velenko <Alex.Velenko@arm.com>
tbsaunde = Trevor Saunders <tbsaunde@tbsaunde.org>
ccoutant = Cary Coutant <ccoutant@gmail.com>
krebbel = Andreas Krebbel <Andreas.Krebbel@de.ibm.com>
tbsaunde = Trevor Saunders <tsaunders@mozilla.com>
wilson = Jim Wilson <jim.wilson@linaro.org>
vekumar = Venkataramanan Kumar <venkataramanan.kumar@amd.com>
miyuki = Mikhail Maltsev <maltsevm@gmail.com>
sje = Steve Ellcey <sellcey@mips.com>
krebbel = Andreas Krebbel <krebbel@linux.vnet.ibm.com>
sje = Steve Ellcey <sellcey@imgtec.com>
ienkovich = Ilya Enkovich <enkovich.gnu@gmail.com>
ienkovich = Ilya Enkovich <ilya.enkovich@intel.com>
ibuclaw = Iain Buclaw <ibuclaw@gdcproject.org>
jamesbowman = James Bowman <james.bowman@ftdichip.com>
krebbel = Andreas Krebbel <Andreas.Krebbel@de.ibm.com>
krebbel = Andreas Krebbel <krebbel@linux.vnet.ibm.com>
ienkovich = Ilya Enkovich <enkovich.gnu@gmail.com>
ienkovich = Ilya Enkovich <ilya.enkovich@intel.com>
nsz = Szabolcs Nagy <szabolcs.nagy@arm.com>
tkoenig = Thomas Koenig <tkoenig@netcologne.de>
tkoenig = Thomas Koenig <tkoenig@gcc.gnu.org>
tkoenig = Thomas Koenig <tkoenig@netcologne.de>
tkoenig = Thomas Koenig <tkoenig@gcc.gnu.org>
ienkovich = Ilya Enkovich <enkovich.gnu@gmail.com>
ludo = Ludovic Courtès <ludo@gnu.org>
nathan = Nathan Sidwell <nathan@codesourcery.com>
vehre = Andre Vehreschild <vehre@gcc.gnu.org>
pmatos = Paulo Matos <pmatos@broadcom.com>
hp = Hans-Peter Nilsson <hp@bitrange.com>
bernds = Bernd Schmidt <bernds_cb1@t-online.de>
cesar = Cesar Philippidis <cesar@codesourcery.com>
ville = Ville Voutilainen <ville.voutilainen@gmail.com>
collison = Michael Collison <michael.collison@linaro.org>
vekumar = Venkataramanan Kumar <Venkataramanan.kumar@amd.com>
nathan = Nathan Sidwell <nathan@acm.org>
tbsaunde = Trevor Saunders <tbsaunde@tbsaunde.org>
schwab = Andreas Schwab <schwab@suse.de>
davids = David Sherwood <david.sherwood@arm.com>
dardiss = Simon Dardis <simon.dardis@imgtec.com>
vondele = Joost VandeVondele <vondele@gnu.gcc.org>
nathan = Nathan Sidwell <nathan@codesourcery.com>
nathan = Nathan Sidwell <nathan@acm.org>
hp = Hans-Peter Nilsson <hp@axis.com>
jwlemke = James Lemke <jim@lemke.org>
bonzini = Paolo Bonzini <bonzini@gnu.org>
bernds = Bernd Schmidt <bschmidt@redhat.com>
ktietz = Kai Tietz <ktietz70@googlemail.com>
nathan = Nathan Sidwell <nathan@codesourcery.com>
lkrupp = Louis Krupp <louis.krupp@zoho.com>
nathan = Nathan Sidwell <nathan@acm.org>
afomin = Alexander Fomin <alexander.fomin@intel.com>
nathan = Nathan Sidwell <nathan@codesourcery.com>
alahay01 = Alan Hayward <alan.hayward@arm.com>
pmatos = Paulo Matos <pmatos@linki.tools>
amylaar = Joern Rennecke <joern.rennecke@embecosm.com>
vekumar = Venkataramanan Kumar <venkataramanan.kumar@amd.com>
nathan = Nathan Sidwell <nathan@acm.org>
law = Jeff Law <jeff@redhat.com>
law = Jeff Law <law@redhat.com>
law = Jeff Law <jeff@redhat.com>
nathan = Nathan Sidwell <nathan@codesourcery.com>
kargl = Steven G. Kargl <kargl@gc.gnu.org>
vondele = Joost VandeVondele <vondele@gcc.gnu.org>
law = Jeff Law <law@redhat.com>
claziss = Claudiu Zissulescu <claziss@synopsys.com>
kargl = Steven G. Kargl <kargl@gcc.gnu.org>
kargl = Steven G. Kargl <kargl@gccc.gnu.org>
kargl = Steven G. Kargl <kargl@gcc.gnu.org>
vekumar = Venkataramanan Kumar <Venkataramanan.Kumar@amd.com>
nathan = Nathan Sidwell <nathan@acm.org>
nathan = Nathan Sidwell <nathan@codesourcery.com>
nathan = Nathan Sidwell <nathan@acm.org>
hubicka = Jan Hubicka <jh@suse.cz>
macro = Maciej W. Rozycki <macro@imgtec.com>
hubicka = Jan Hubicka <hubicka@ucw.cz>
evandro = Evandro Menezes <e.menezes@samsung.com>
afanfa = Alessandro Fanfarillo <fanfarillo.gcc@gmail.com>
andris = Andris Pavenis <andris.pavenis@iki.fi>
ssaraswati = Sujoy Saraswati <sujoy.saraswati@hpe.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>
wilco = Wilco Dijkstra <wdijkstr@arm.com>
nathan = Nathan Sidwell <nathan@codesourcery.com>
vekumar = Venkataramanan Kumar <venkataramanan.kumar@amd.com>
kelvin = Kelvin Nilsen <kelvin@gcc.gnu.org>
joel = Joel Sherrill <joel@rtems.org>
vekumar = Venkataramanan Kumar <Venkataramanan.kumar@amd.com>
vekumar = Venkataramanan Kumar <venkataramanan.kumar@amd.com>
nathan = Nathan Sidwell <nathan@acm.org>
schwab = Andreas Schwab <schwab@suse.de>
kelvin = Kelvin Nilsen <kdnilsen@linux.vnet.ibm.com>
seurer = Bill Seurer <seurer@linux.vnet.ibm.com>
chefmax = Maxim Ostapenko <m.ostapenko@samsung.com>
avieira = Andre Vieira <andre.simoesdiasvieira@arm.com>
ienkovich = Ilya Enkovich <ilya.enkovich@intel.com>
hubicka = Jan Hubicka <jh@suse.cz>
charlet = Arnaud Charlet <charleT@adacore.com>
charlet = Arnaud Charlet <charlet@adacore.com>
doko = Matthias Klose <doko@debian.org>
tromey = Tom Tromey <tom@tromey.com>
nathan = Nathan Sidwell <nathan@codesourcery.com>
hubicka = Jan Hubicka <hubicka@ucw.cz>
acsawdey = Aaron Sawdey <acsawdey@linux.vnet.ibm.com>
nathan = Nathan Sidwell <nathan@acm.org>
doko = Matthias Klose <doko@ubuntu.com>
kelvin = Kelvin Nilsen <kelvin@gcc.gnu.org>
uweigand = Ulrich Weigand <uweigand@de.ibm.com>
sayle = Roger Sayle <roger@nextmovesoftware.com>
jemarch = Jose E. Marchesi <jose.marchesi@oracle.com>
hubicka = Jan Hubicka <jh@suse.cz>
hubicka = Jan Hubicka <hubicka@ucw.cz>
jyong = Jonathan Yong <10walls@gmail.com>
collison = Michael Collison <michael.collison@arm.com>
saaadhu = Senthil Kumar Selvaraj <senthil_kumar.selvaraj@atmel.com>
ksejdak = Jakub Sejdak <jakub.sejdak@phoesys.com>
hubicka = Jan Hubicka <jh@suse.cz>
hubicka = Jan Hubicka <hubicka@ucw.cz>
schwab = Andreas Schwab <schwab@linux-m68k.org>
foreese = Fritz Reese <fritzoreese@gmail.com>
schwab = Andreas Schwab <schwab@suse.de>
nathan = Nathan Sidwell <nathan@codesourcery.com>
nathan = Nathan Sidwell <nathan@acm.org>
ian = Ian Lance Taylor <iant@golang.org>
collison = Michael Collison <michael.collison@linaro.org>
ian = Ian Lance Taylor <iant@google.com>
iverbin = Ilya Verbin <iverbin@gmail.com>
kyukhin = Kirill Yukhin <kirill.yukhin@gmaile.com>
kyukhin = Kirill Yukhin <kirill.yukhin@intel.com>
ian = Ian Lance Taylor <iant@golang.org>
lkrupp = Louis Krupp <louis.krupp@gmail.com>
kyukhin = Kirill Yukhin <kirill.yukhin@gmaile.com>
lkrupp = Louis Krupp <louis.krupp@zoho.com>
tnfchris = Tamar Christina <tamar.christina@arm.com>
nathan = Nathan Sidwell <nathan@codesourcery.com>
nathan = Nathan Sidwell <nathan@acm.org>
sje = Steve Ellcey <sellcey@caviumnetworks.com>
kargl = Steven G. Kargl <kargls@gcc.gnu.org>
kargl = Steven G. Kargl <kargl@gcc.gnu.org>
vekumar = Venkataramanan Kumar <Venkataramanan.kumar@amd.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>
kugan = Kugan Vivekanandarajah <kuganvi@linaro.org>
willschm = Will Schmidt <will_schmidt@vnet.ibm.com>
aburgess = Andrew Burgess <andrew.burgess@embecosm.com>
carll = Carl Love <cel@us.ibm.com>
jconner = Josh Conner <joshconner@google.com>
kugan = Kugan Vivekanandarajah <kuganv@linaro.org>
schwab = Andreas Schwab <schwab@suse.de>
mark = Mark Wielaard <mark@klomp.org>
tomtab = Toma Tabacu <toma.tabacu@imgtec.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>
ian = Ian Lance Taylor <iant@google.com>
ian = Ian Lance Taylor <iant@golang.org>
collison = Michael Collison <michael.collison@arm.com>
prathamesh3492 = Prathamesh Kulkarni <prathamesh.kulkarni@linaro.rog>
prathamesh3492 = Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org>
naveenh = Naveen H.S <Naveen.Hurugalawadi@cavium.com>
paulhua = Chenghua Xu <paul.hua.gm@gmail.com>
jgreenhalgh = James Greenhalgh <james.greenhalghj@arm.com>
aivchenk = Alexander Ivchenko <alexander.ivchenko@intel.com>
ian = Ian Lance Taylor <iant@google.com>
ian = Ian Lance Taylor <iant@golang.org>
tkoenig = Thomas Koenig <tkoenig@netcologne.de>
kyukhin = Kirill Yukhin <kirill.yukhin@gmail.com>
rearnsha = Richard Earnshaw <rearnsh@arm.com>
ian = Ian Lance Taylor <iant@google.com>
ian = Ian Lance Taylor <iant@golang.org>
visit0r = Pekka Jääskeläinen <pekka.jaaskelainen@parmance.com>
dgilmore = Doug Gilmore <Doug.Gilmore@imgtec.com>
palmer = Palmer Dabbelt <palmer@dabbelt.com>
tkoenig = Thomas Koenig <tkoenig@gcc.gnu.org>
jgreenhalgh = James Greenhalgh <james.greenhalgh@arm.com>
rearnsha = Richard Earnshaw <rearnsha@arm.com>
koenigni = Nicolas Koenig <koenigni@gcc.gnu.org>
koenigni = Nicolas Koenig <koenigni@student.ethz.ch>
ian = Ian Lance Taylor <iant@google.com>
schwab = Andreas Schwab <schwab@suse.de>
schwab = Andreas Schwab <schwab@linux-m68k.org>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
sje = Steve Ellcey <sellcey@cavium.com>
rsandifo = Richard Sandiford <richard.sandiford@arm.com>
ian = Ian Lance Taylor <iant@golang.org>
munroesj = Steven Munroe <munroesj@gcc.gnu.org>
ian = Ian Lance Taylor <iant@google.com>
smlobo = Sheldon Lobo <sheldon.lobo@oracle.com>
ian = Ian Lance Taylor <iant@golang.org>
schwab = Andreas Schwab <schwab@suse.de>
smlobo = Sheldon Lobo <smlobo@sheldon.us.oracle.com>
egallager = Eric Gallager <egall@gwmail.gwu.edu>
prakhar = Prakhar Bahuguna <prakhar.bahuguna@arm.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
schwab = Andreas Schwab <schwab@linux-m68k.org>
aivchenk = Alexander Ivchenko <aivchenk@gmail.com>
aivchenk = Alexander Ivchenko <alexander.ivchenko@intel.com>
schwab = Andreas Schwab <schwab@suse.de>
ebotcazou = Eric Botcazou <ebotcazou@libertysurf.fr>
ebotcazou = Eric Botcazou <ebotcazou@adacore.com>
wilson = Jim Wilson <jim.wilson@r3-a15.aus-colo>
vapier = Mike Frysinger <vapier@chromium.org>
ygribov = Yury Gribov <tetra2005@gmail.com>
drepper = Ulrich Drepper <drepper@redhat.com>
wilson = Jim Wilson <jim.wilson@linaro.org>
dansan = Daniel Santos <daniel.santos@pobox.com>
rdapp = Robin Dapp <rdapp@linux.vnet.ibm.com>
rth = Richard Henderson <rth@twiddle.net>
foreese = Fritz Reese <Reese-Fritz@zai.com>
foreese = Fritz Reese <fritzoreese@gmail.com>
ian = Ian Lance Taylor <iant@google.com>
ian = Ian Lance Taylor <iant@golang.org>
qiyao = Yao Qi <yao.qi@linaro.org>
schwab = Andreas Schwab <schwab@linux-m68k.org>
ian = Ian Lance Taylor <iant@google.com>
ian = Ian Lance Taylor <iant@golang.org>
rsandifo = Richard Sandiford <richard.sandifird@linaro.org>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
wilson = Jim Wilson <wilson@tuliptree.org>
azanella = Adhemerval Zanella <adhemerval.zanella@linaro.org>
itsimbal = Igor Tsimbalist <igor.v.tsimbalist@intel.com>
segher = Segher Boessenkool <segher@kernel.crsahing.org>
segher = Segher Boessenkool <segher@kernel.crashing.org>
schwab = Andreas Schwab <schwab@suse.de>
kargl = Steven G. Kargl <kargl@kgcc.gnu.org>
wilson = Jim Wilson <jimw@sifive.com>
kargl = Steven G. Kargl <kargl@gcc.gnu.org>
luisgpm = Luis Machado <luis.machado@linaro.org>
speryt = Sebastian Peryt <sebastian.peryt@intel.com>
palmer = Palmer Dabbelt <palmer@sifive.com>
sudi = Sudakshina Das <sudi.das@arm.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>
jkoval = Julia Koval <julia.koval@intel.com>
qinzhao = Qing Zhao <qing.zhao@oracle.com>
rsandifo = Richard Sandiford <richard.sandiford@arm.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
munroesj = Steven Munroe <munroesj52@gmail.com>
dominiq = Dominique d'Humieres <dominiq@gcc.gnu.org>
andrewjenner = Andrew Jenner <andrew@codeourcery.com>
munroesj = Steven Munroe <munroesj@gcc.gnu.org>
schwab = Andreas Schwab <schwab@suse.de>
macro = Maciej W. Rozycki <macro@mips.com>
mpf = Matthew Fortune <mfortune@gmail.com>
kargl = Steven G. Kargl <kargls@gcc.gnu.org>
kargl = Steven G. Kargl <kargl@gcc.gnu.org>
rsandifo = Richard Sandiford <richard.sandiford@arm.com>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
hubicka = Jan Hubicka <jh@suse.cz>
acsawdey = Aaron Sawdey <acsawdey@linux.ibm.com>
hubicka = Jan Hubicka <hubicka@ucw.cz>
krebbel = Andreas Krebbel <krebbel@linux.ibm.com>
hubicka = Jan Hubicka <jh@suse.cz>
meissner = Michael Meissner <meissner@linux.ibm.com>
law = Jeff Law <law@redhat.comg>
meissner = Michael Meissner <meissner@linux.vnet.ibm.com>
meissner = Michael Meissner <meissner@linux.ibm.com>
hubicka = Jan Hubicka <hubicka@ucw.cz>
hubicka = Jan Hubicka <jh@suse.cz>
hubicka = Jan Hubicka <hubicka@ucw.cz>
sameerad = Sameera Deshpande <sameera.deshpande@linaro.org>
vries = Tom de Vries <tdevries@suse.de>
amker = Bin Cheng <amker@gcc.gnu.org>
schwab = Andreas Schwab <schwab@linux-m68k.org>
rts = Robert Suchanek <robert.suchanek@mips.com>
hjl = H.J. Lu <hjl.tools@gmail.com>
law = Jeff Law <law@redhat.com>
hubicka = Jan Hubicka <hubicka@gcc.gnu.org>
hubicka = Jan Hubicka <hubicka@ucw.cz>
rsandifo = Richard Sandiford <richard.sandiford@arm.com>
aoliva = Alexandre Oliva <oliva@adacore.com>
rth = Richard Henderson <richard.henderson@linaro.org>
hjl = H.J. Lu <hongjiu.lu@intel.com>
bergner = Peter Bergner <bergner@linux.ibm.com>
kugan = Kugan Vivekanandarajah <kugan.vivekanandarajah@linaro.org>
rsandifo = Richard Sandiford <richard.sandiford@linaro.org>
kugan = Kugan Vivekanandarajah <kuganv@linaro.org>
rdapp = Robin Dapp <rdapp@linux.ibm.com>
rsandifo = Richard Sandiford <richard.sandiford@arm.com>
koenigni = Nicolas Koenig <koenigni@gcc.gnu.org>
thopre01 = Thomas Preud'homme <thomas.preudhomme@linaro.org>
naveenh = Naveen H.S <naveenh@marvell.com>
schwab = Andreas Schwab <schwab@suse.de>
iains = Iain Sandoe <iain@sandoe.co.uk>
hubicka = Jan Hubicka <jh@suse.cz>
aoliva = Alexandre Oliva <aoliva@redhat.com>
aoliva = Alexandre Oliva <oliva@adacore.com>
jb = Janne Blomqvist <blomqvist.janne@gmail.com>
amylaar = Joern Rennecke <joern.rennecke@riscy-ip.com>
xguo = Xuepeng Guo <xuepeng.guo@intel.com>
jb = Janne Blomqvist <jb@gcc.gnu.org>
hp = Hans-Peter Nilsson <hp@bitrange.com>
edlinger = Bernd Edlinger <msebor@redhat.com>
edlinger = Bernd Edlinger <bernd.edlinger@hotmail.de>
aoliva = Alexandre Oliva <aoliva@redhat.com>
aoliva = Alexandre Oliva <oliva@adacore.com>
pinskia = Andrew Pinski <apinski@marvell.com>
ian = Ian Lance Taylor <iant@google.com>
ian = Ian Lance Taylor <iant@golang.org>
amker = Bin Cheng <bin.cheng@linux.alibaba.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>
hubicka = Jan Hubicka <hubicka@ucw.cz>
aoliva = Alexandre Oliva <aoliva@redhat.com>
hubicka = Jan Hubicka <jh@suse.cz>
vekumar = Venkataramanan Kumar <venkataramanan.kumar@amd.com>
aoliva = Alexandre Oliva <oliva@adacore.com>
hp = Hans-Peter Nilsson <hp@axis.com>
macro = Maciej W. Rozycki <macro@linux-mips.org>
hubicka = Jan Hubicka <hubicka@ucw.cz>
hubicka = Jan Hubicka <jh@suse.cz>
hubicka = Jan Hubicka <hubicka@ucw.cz>
schwab = Andreas Schwab <schwab@suse.de>
hubicka = Jan Hubicka <jh@suse.cz>
hubicka = Jan Hubicka <hubicka@ucw.cz>
hubicka = Jan Hubicka <jh@suse.cz>
hubicka = Jan Hubicka <hubicka@ucw.cz>
aoliva = Alexandre Oliva <aoliva@redhat.com>
thopre01 = Thomas Preud'homme <thomas.preudhomme@arm.com>
saaadhu = Senthil Kumar Selvaraj <senthilkumar.selvaraj@microchip.com>
vries = Tom de Vries <tom@codesourcery.com>
vries = Tom de Vries <tdevries@suse.de>
thopre01 = Thomas Preud'homme <thomas.preudhomme@linaro.org>
aoliva = Alexandre Oliva <oliva@adacore.com>
hubicka = Jan Hubicka <jh@suse.cz>
hubicka = Jan Hubicka <hubicka@ucw.cz>
sje = Steve Ellcey <sellcey@marvell.com>
aoliva = Alexandre Oliva <aoliva@redhat.com>
sje = Steve Ellcey <sellcey@cavium.com>
sje = Steve Ellcey <sellcey@marvell.com>
rguenth = Richard Biener;Richard Guenther <rguenth@suse.de>
rguenth = Richard Biener;Richard Guenther <rguenther@suse.de>
danglin = John David Anglin <dave.anglin@bell.net>
danglin = John David Anglin <danglin@gcc.gnu.org>
tkoenig = Thomas Koenig <tkoeng@gcc.gnu.org>
tkoenig = Thomas Koenig <tkoenig@gcc.gnu.org>
claziss = Claudiu Zissulescu <claziss@gmail.com>
claziss = Claudiu Zissulescu <claziss@synopsys.com>
amylaar = Joern Rennecke <joern.rennecke@embecosm.com>
macro = Maciej W. Rozycki <macro@wdc.com>
ams = Andrew Stubbs <amd@codesourcery.com>
hubicka = Jan Hubicka <jh@suse.cz>
ams = Andrew Stubbs <ams@codesourcery.com>
hubicka = Jan Hubicka <hubicka@ucw.cz>
hubicka = Jan Hubicka <jh@suse.cz>
hubicka = Jan Hubicka <hubicka@ucw.cz>
danglin = John David Anglin <danglin@gcc.gnu.orig>
danglin = John David Anglin <danglin@gcc.gnu.org>
rguenth = Richard Biener;Richard Guenther <rguenthe@suse.de>
rguenth = Richard Biener;Richard Guenther <rguenther@suse.de>
kugan = Kugan Vivekanandarajah <kugan.vivekanandarajah@linaro.org>
aoliva = Alexandre Oliva <oliva@adacore.com>
hubicka = Jan Hubicka <jh@suse.cz>
hubicka = Jan Hubicka <hubicka@ucw.cz>
amylaar = Joern Rennecke <joern.rennecke@riscy-ip.com>
hubicka = Jan Hubicka <jh@suse.cz>
hubicka = Jan Hubicka <hubicka@ucw.cz>
hubicka = Jan Hubicka <jh@suse.cz>
schwab = Andreas Schwab <schwab@linux-m68k.org>
hubicka = Jan Hubicka <hubicka@ucw.cz>
hubicka = Jan Hubicka <jh@suse.cz>
schwab = Andreas Schwab <schwab@suse.de>
hubicka = Jan Hubicka <hubicka@ucw.cz>
amker = Bin Cheng <bin.linux@linux.alibaba.com>
schwab = Andreas Schwab <schwab@linux-m68k.org>

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Joseph Myers]

On Tue, 14 May 2019, Maxim Kuvyrkov wrote:

> The scripts convert svn history branch by branch.  They rely on git-svn 
> on convert individual branches.  Git-svn is a good tool for converting 
> individual branches.  It is, however, either very slow at converting the 
> entire GCC repo, or goes into infinite loop.

I think git-svn is in fact a bad tool for repository conversion when the 
history is nontrivial (for the reasons that have been discussed at length 
in the past), and we should convert with reposurgeon.

ESR, can you give an update on the status of the conversion with 
reposurgeon?  You said "another serious attack on the repository 
conversion is probably about two months out" in 
<https://gcc.gnu.org/ml/gcc/2018-12/msg00112.html>.  Is it on target to be 
done by the time of the GNU Tools Cauldron in Montreal in September?

And, could you bring git://thyrsus.com/repositories/gcc-conversion.git up 
to date with changes since Jan 2018, or push the latest version of that 
repository to some other public hosting location?  That repository 
represents what I consider the collaboratively built consensus on such 
things as the desired author map (including handling of the ambiguous 
author name), which directories represent branches and tags, and what tags 
should be kept or removed - but building up such a consensus and keeping 
it up to date over time (for new committers etc.) requires that the public 
repository actually reflects the latest version of the conversion 
machinery, day by day as the consensus develops.  Review of that 
repository will be important for reviewing the details of whether the 
conversion is being done as desired - the details of the machinery will 
help suggest things to spot-check in a converted repository.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Martin Liška]

On 5/17/19 1:06 AM, Joseph Myers wrote:
> That repository 
> represents what I consider the collaboratively built consensus on such 
> things as the desired author map (including handling of the ambiguous 
> author name), which directories represent branches and tags, and what tags 
> should be kept or removed - but building up such a consensus and keeping 

About the map. I agree with Richard that we should do best approach and not
to fully reconstruct history of people who has switched email address multi
times. I cloned git://thyrsus.com/repositories/gcc-conversion.git and made
a clean up:

- for logins with duplicite emails I chose the latest one used on gcc-patches mailing list
- comments were removed
- a few entries contained timezone and I stripped that

Final version of the map can be seen here:
https://github.com/marxin/gcc-git-conversion/blob/cleanup/gcc.map

@Maxim: would it be possible to update your script so that it will use:
--authors-file=gcc.map ?

Is it desired for the transition to use the author map? Do we want it?

Martin

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Jakub Jelinek]

On Fri, May 17, 2019 at 02:22:47PM +0200, Martin Liška wrote:
> On 5/17/19 1:06 AM, Joseph Myers wrote:
> > That repository 
> > represents what I consider the collaboratively built consensus on such 
> > things as the desired author map (including handling of the ambiguous 
> > author name), which directories represent branches and tags, and what tags 
> > should be kept or removed - but building up such a consensus and keeping 
> 
> About the map. I agree with Richard that we should do best approach and not
> to fully reconstruct history of people who has switched email address multi
> times. I cloned git://thyrsus.com/repositories/gcc-conversion.git and made
> a clean up:
> 
> - for logins with duplicite emails I chose the latest one used on gcc-patches mailing list
> - comments were removed
> - a few entries contained timezone and I stripped that
> 
> Final version of the map can be seen here:
> https://github.com/marxin/gcc-git-conversion/blob/cleanup/gcc.map
> 
> @Maxim: would it be possible to update your script so that it will use:
> --authors-file=gcc.map ?
> 
> Is it desired for the transition to use the author map? Do we want it?

Can people proposing the conversion also come up with the precommit hooks
etc. scripts we'll need?
I'd think we want to enforce linear history (and stress that every commit
should be bootstrappable, with git it is much easier to screw that up by
pushing many git commits at once, even with rebase actually not testing each
of them).
And something to keep the numeric commit numbers working for
http://gcc.gnu.org/rNNNNNN (I believe a roughly working scheme has been
identified, but not implemented).

	Jakub

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Martin Liška]

On 5/17/19 2:39 PM, Jakub Jelinek wrote:
> On Fri, May 17, 2019 at 02:22:47PM +0200, Martin Liška wrote:
>> On 5/17/19 1:06 AM, Joseph Myers wrote:
>>> That repository
>>> represents what I consider the collaboratively built consensus on such
>>> things as the desired author map (including handling of the ambiguous
>>> author name), which directories represent branches and tags, and what tags
>>> should be kept or removed - but building up such a consensus and keeping
>>
>> About the map. I agree with Richard that we should do best approach and not
>> to fully reconstruct history of people who has switched email address multi
>> times. I cloned git://thyrsus.com/repositories/gcc-conversion.git and made
>> a clean up:
>>
>> - for logins with duplicite emails I chose the latest one used on gcc-patches mailing list
>> - comments were removed
>> - a few entries contained timezone and I stripped that
>>
>> Final version of the map can be seen here:
>> https://github.com/marxin/gcc-git-conversion/blob/cleanup/gcc.map
>>
>> @Maxim: would it be possible to update your script so that it will use:
>> --authors-file=gcc.map ?
>>
>> Is it desired for the transition to use the author map? Do we want it?
> 
> Can people proposing the conversion also come up with the precommit hooks
> etc. scripts we'll need?

Can you please point out to a discussion where these were mentioned?
I'm aware of 'no-merge-commits hook' and a hook that will paste commit
message to bugzilla entries.

> I'd think we want to enforce linear history (and stress that every commit
> should be bootstrappable, with git it is much easier to screw that up by
> pushing many git commits at once, even with rebase actually not testing each
> of them).
> And something to keep the numeric commit numbers working for
> http://gcc.gnu.org/rNNNNNN (I believe a roughly working scheme has been
> identified, but not implemented).

Do we really need a commit integer numbers after the transition? I know we're used to it.
But git commit hash provides that same.

Martin

> 
> 	Jakub
> 

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Segher Boessenkool]

On Sun, May 19, 2019 at 09:35:45AM +0200, Martin Liška wrote:
> Do we really need a commit integer numbers after the transition? I know 
> we're used to it.
> But git commit hash provides that same.

Revision numbers are nice short text strings, and from a revision number
you can see approximately when it happened, and from two revision numbers
on the same branch you can trivially tell which one is older.  Those are
nice features.  But we can live without it, IMO.


Segher

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Marek Polacek]

On Sun, May 19, 2019 at 03:11:08AM -0500, Segher Boessenkool wrote:
> On Sun, May 19, 2019 at 09:35:45AM +0200, Martin Liška wrote:
> > Do we really need a commit integer numbers after the transition? I know 
> > we're used to it.
> > But git commit hash provides that same.
> 
> Revision numbers are nice short text strings, and from a revision number
> you can see approximately when it happened, and from two revision numbers
> on the same branch you can trivially tell which one is older.  Those are
> nice features.  But we can live without it, IMO.

Since I do many bisections a day, losing this capability would be Very Bad.
Without it, there's no range, and without a range, there's nothing to _bisect_.

I bisect by hand, so if I have cc1plus.250000 (good) and cc1plus.260000 (bad),
I know the commit I'm looking for is within that range, and I can easily split
the range, and it's at most log n steps.  Whereas if we had e.g. cc1plus.de28b0
and cc1plus.a9bd4d, I couldn't do it anymore.

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Andreas Schwab]

On Mai 19 2019, Marek Polacek <polacek@redhat.com> wrote:

> On Sun, May 19, 2019 at 03:11:08AM -0500, Segher Boessenkool wrote:
>> On Sun, May 19, 2019 at 09:35:45AM +0200, Martin Liška wrote:
>> > Do we really need a commit integer numbers after the transition? I know 
>> > we're used to it.
>> > But git commit hash provides that same.
>> 
>> Revision numbers are nice short text strings, and from a revision number
>> you can see approximately when it happened, and from two revision numbers
>> on the same branch you can trivially tell which one is older.  Those are
>> nice features.  But we can live without it, IMO.
>
> Since I do many bisections a day, losing this capability would be Very Bad.
> Without it, there's no range, and without a range, there's nothing to _bisect_.

What's wrong with git bisect?  It does everything you need.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Segher Boessenkool]

On Sun, May 19, 2019 at 03:21:01PM -0400, Marek Polacek wrote:
> On Sun, May 19, 2019 at 03:11:08AM -0500, Segher Boessenkool wrote:
> > On Sun, May 19, 2019 at 09:35:45AM +0200, Martin Liška wrote:
> > > Do we really need a commit integer numbers after the transition? I know 
> > > we're used to it.
> > > But git commit hash provides that same.
> > 
> > Revision numbers are nice short text strings, and from a revision number
> > you can see approximately when it happened, and from two revision numbers
> > on the same branch you can trivially tell which one is older.  Those are
> > nice features.  But we can live without it, IMO.
> 
> Since I do many bisections a day, losing this capability would be Very Bad.
> Without it, there's no range, and without a range, there's nothing to _bisect_.
> 
> I bisect by hand, so if I have cc1plus.250000 (good) and cc1plus.260000 (bad),
> I know the commit I'm looking for is within that range, and I can easily split
> the range, and it's at most log n steps.  Whereas if we had e.g. cc1plus.de28b0
> and cc1plus.a9bd4d, I couldn't do it anymore.

Git can bisect automatically just fine, there is no upside to doing things
manually.  In git there are various handy ways of referring to commits; you
can say  master@{3 days ago}  for example, or zut@{31}  to get the 31st
commit back on branch "zut", etc.  See "man gitrevisions".


Segher

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Andrew Pinski]

On Sun, May 19, 2019 at 12:54 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Sun, May 19, 2019 at 03:21:01PM -0400, Marek Polacek wrote:
> > On Sun, May 19, 2019 at 03:11:08AM -0500, Segher Boessenkool wrote:
> > > On Sun, May 19, 2019 at 09:35:45AM +0200, Martin Liška wrote:
> > > > Do we really need a commit integer numbers after the transition? I know
> > > > we're used to it.
> > > > But git commit hash provides that same.
> > >
> > > Revision numbers are nice short text strings, and from a revision number
> > > you can see approximately when it happened, and from two revision numbers
> > > on the same branch you can trivially tell which one is older.  Those are
> > > nice features.  But we can live without it, IMO.
> >
> > Since I do many bisections a day, losing this capability would be Very Bad.
> > Without it, there's no range, and without a range, there's nothing to _bisect_.
> >
> > I bisect by hand, so if I have cc1plus.250000 (good) and cc1plus.260000 (bad),
> > I know the commit I'm looking for is within that range, and I can easily split
> > the range, and it's at most log n steps.  Whereas if we had e.g. cc1plus.de28b0
> > and cc1plus.a9bd4d, I couldn't do it anymore.
>
> Git can bisect automatically just fine, there is no upside to doing things
> manually.  In git there are various handy ways of referring to commits; you
> can say  master@{3 days ago}  for example, or zut@{31}  to get the 31st
> commit back on branch "zut", etc.  See "man gitrevisions".

Well one thing is if you have prebuilt cc1/cc1plus.  So it is not
really doing a manual bisect per-say but rather it is doing a manual
bisect using prebuilt binaries and knowing which one comes before
which one.
One way is store the binaries based on the date that commit happened
instead.  This is a bit more complex but still doable.

Thanks,
Andrew Pinski

>
>
> Segher

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Marek Polacek]

On Sun, May 19, 2019 at 01:00:45PM -0700, Andrew Pinski wrote:
> On Sun, May 19, 2019 at 12:54 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> >
> > On Sun, May 19, 2019 at 03:21:01PM -0400, Marek Polacek wrote:
> > > On Sun, May 19, 2019 at 03:11:08AM -0500, Segher Boessenkool wrote:
> > > > On Sun, May 19, 2019 at 09:35:45AM +0200, Martin Liška wrote:
> > > > > Do we really need a commit integer numbers after the transition? I know
> > > > > we're used to it.
> > > > > But git commit hash provides that same.
> > > >
> > > > Revision numbers are nice short text strings, and from a revision number
> > > > you can see approximately when it happened, and from two revision numbers
> > > > on the same branch you can trivially tell which one is older.  Those are
> > > > nice features.  But we can live without it, IMO.
> > >
> > > Since I do many bisections a day, losing this capability would be Very Bad.
> > > Without it, there's no range, and without a range, there's nothing to _bisect_.
> > >
> > > I bisect by hand, so if I have cc1plus.250000 (good) and cc1plus.260000 (bad),
> > > I know the commit I'm looking for is within that range, and I can easily split
> > > the range, and it's at most log n steps.  Whereas if we had e.g. cc1plus.de28b0
> > > and cc1plus.a9bd4d, I couldn't do it anymore.
> >
> > Git can bisect automatically just fine, there is no upside to doing things
> > manually.  In git there are various handy ways of referring to commits; you
> > can say  master@{3 days ago}  for example, or zut@{31}  to get the 31st
> > commit back on branch "zut", etc.  See "man gitrevisions".
> 
> Well one thing is if you have prebuilt cc1/cc1plus.  So it is not
> really doing a manual bisect per-say but rather it is doing a manual
> bisect using prebuilt binaries and knowing which one comes before
> which one.

Exactly, we have many TBs of prebuilt binaries.

> One way is store the binaries based on the date that commit happened
> instead.  This is a bit more complex but still doable.

Yeah, I guess we'll have to do something like that, then.  :/

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Martin Liška]

On 5/19/19 10:06 PM, Marek Polacek wrote:
> On Sun, May 19, 2019 at 01:00:45PM -0700, Andrew Pinski wrote:
>> On Sun, May 19, 2019 at 12:54 PM Segher Boessenkool
>> <segher@kernel.crashing.org> wrote:
>>>
>>> On Sun, May 19, 2019 at 03:21:01PM -0400, Marek Polacek wrote:
>>>> On Sun, May 19, 2019 at 03:11:08AM -0500, Segher Boessenkool wrote:
>>>>> On Sun, May 19, 2019 at 09:35:45AM +0200, Martin Liška wrote:
>>>>>> Do we really need a commit integer numbers after the transition? I know
>>>>>> we're used to it.
>>>>>> But git commit hash provides that same.
>>>>>
>>>>> Revision numbers are nice short text strings, and from a revision number
>>>>> you can see approximately when it happened, and from two revision numbers
>>>>> on the same branch you can trivially tell which one is older.  Those are
>>>>> nice features.  But we can live without it, IMO.
>>>>
>>>> Since I do many bisections a day, losing this capability would be Very Bad.
>>>> Without it, there's no range, and without a range, there's nothing to _bisect_.
>>>>
>>>> I bisect by hand, so if I have cc1plus.250000 (good) and cc1plus.260000 (bad),
>>>> I know the commit I'm looking for is within that range, and I can easily split
>>>> the range, and it's at most log n steps.  Whereas if we had e.g. cc1plus.de28b0
>>>> and cc1plus.a9bd4d, I couldn't do it anymore.
>>>
>>> Git can bisect automatically just fine, there is no upside to doing things
>>> manually.  In git there are various handy ways of referring to commits; you
>>> can say  master@{3 days ago}  for example, or zut@{31}  to get the 31st
>>> commit back on branch "zut", etc.  See "man gitrevisions".
>>
>> Well one thing is if you have prebuilt cc1/cc1plus.  So it is not
>> really doing a manual bisect per-say but rather it is doing a manual
>> bisect using prebuilt binaries and knowing which one comes before
>> which one.
> 
> Exactly, we have many TBs of prebuilt binaries.

I combine both together, feel free to use my script:
https://github.com/marxin/script-misc/blob/master/gcc-bisect.py

It uses git repository for navigation, information about branches, tag releases
and so on. And then I have a folder with pre-built binaries which are identified
by commit hash. That works all fine.

Martin

> 
>> One way is store the binaries based on the date that commit happened
>> instead.  This is a bit more complex but still doable.
> 
> Yeah, I guess we'll have to do something like that, then.  :/
> 
> --
> Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA
> 

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Florian Weimer]

* Andrew Pinski:

> On Sun, May 19, 2019 at 12:54 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:

>> Git can bisect automatically just fine, there is no upside to doing things
>> manually.  In git there are various handy ways of referring to commits; you
>> can say  master@{3 days ago}  for example, or zut@{31}  to get the 31st
>> commit back on branch "zut", etc.  See "man gitrevisions".
>
> Well one thing is if you have prebuilt cc1/cc1plus.  So it is not
> really doing a manual bisect per-say but rather it is doing a manual
> bisect using prebuilt binaries and knowing which one comes before
> which one.

If GCC policy is to reject merge commits, a command similar to
“git log --pretty=oneline | wc -l” gives something that is very
much like a Subversion revision number, in the sense that it matches
the commit ordering and that the assigned numbers remain stable
over time.

Thanks,
Florian

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Segher Boessenkool]

On Mon, May 20, 2019 at 03:56:35PM +0200, Florian Weimer wrote:
> If GCC policy is to reject merge commits, a command similar to
> “git log --pretty=oneline | wc -l” gives something that is very
> much like a Subversion revision number, in the sense that it matches
> the commit ordering and that the assigned numbers remain stable
> over time.

Yup.  About twice faster:

git rev-list --count <branch>


Segher

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Jakub Jelinek]

On Mon, May 20, 2019 at 03:56:35PM +0200, Florian Weimer wrote:
> * Andrew Pinski:
> 
> > On Sun, May 19, 2019 at 12:54 PM Segher Boessenkool
> > <segher@kernel.crashing.org> wrote:
> 
> >> Git can bisect automatically just fine, there is no upside to doing things
> >> manually.  In git there are various handy ways of referring to commits; you
> >> can say  master@{3 days ago}  for example, or zut@{31}  to get the 31st
> >> commit back on branch "zut", etc.  See "man gitrevisions".
> >
> > Well one thing is if you have prebuilt cc1/cc1plus.  So it is not
> > really doing a manual bisect per-say but rather it is doing a manual
> > bisect using prebuilt binaries and knowing which one comes before
> > which one.
> 
> If GCC policy is to reject merge commits, a command similar to
> “git log --pretty=oneline | wc -l” gives something that is very
> much like a Subversion revision number, in the sense that it matches
> the commit ordering and that the assigned numbers remain stable
> over time.

That is way too slow for our purposes, note we have at least 150000 trunk
commits at least, git log --pretty=oneline | wc -l takes on my box more than
1.4 seconds.

So far the best suggestion I was given for this was:
> so, if we have tags like r163 for 163000'th commit then git describe --all --match 'r[0-9]*' whatever | sed 's/^r\([0-9]\)*-\([0-9]\)*-.*$/\1\2/'
> would give us the r163147 (except it doesn't handle the r163000 commit or < 100 commits after it, to be fixed)
matz> yeah.  With the other direction then being as discussed above (limiting the git log revision to just the couple thousands in range).  One thing to consider: having a zillion tags locally can make other operations slow (as the mapping from SHA1 to tag is slow), so if really using rXXX tags it should probably be a larger range than just 1000 revisions.

Thus perhaps tag in a post-commit hook every 5000th commit and handle the
rest in some git alias command or script that.  We need a quick way to map
between these revisions and hashes bidirectionally.
Unfortunately, the above is just a per-branch number rather than branch
number common to trunk and official release branches.

	Jakub

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Andreas Schwab]

On Mai 20 2019, Florian Weimer <fweimer@redhat.com> wrote:

> If GCC policy is to reject merge commits, a command similar to
> “git log --pretty=oneline | wc -l” gives something that is very

git rev-list HEAD | wc -l

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Jakub Jelinek]

On Mon, May 20, 2019 at 04:26:45PM +0200, Andreas Schwab wrote:
> On Mai 20 2019, Florian Weimer <fweimer@redhat.com> wrote:
> 
> > If GCC policy is to reject merge commits, a command similar to
> > “git log --pretty=oneline | wc -l” gives something that is very
> 
> git rev-list HEAD | wc -l

That is still in the 1.3 seconds range, git rev-list --count HEAD | wc -l
is in the 1 seconds range user time.

	Jakub

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Andreas Schwab]

On Mai 20 2019, Jakub Jelinek <jakub@redhat.com> wrote:

> On Mon, May 20, 2019 at 04:26:45PM +0200, Andreas Schwab wrote:
>> On Mai 20 2019, Florian Weimer <fweimer@redhat.com> wrote:
>> 
>> > If GCC policy is to reject merge commits, a command similar to
>> > “git log --pretty=oneline | wc -l” gives something that is very
>> 
>> git rev-list HEAD | wc -l
>
> That is still in the 1.3 seconds range, git rev-list --count HEAD | wc -l
> is in the 1 seconds range user time.

You don't want the wc -l any more, though. :-)

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Segher Boessenkool]

On Mon, May 20, 2019 at 04:29:10PM +0200, Jakub Jelinek wrote:
> On Mon, May 20, 2019 at 04:26:45PM +0200, Andreas Schwab wrote:
> > On Mai 20 2019, Florian Weimer <fweimer@redhat.com> wrote:
> > 
> > > If GCC policy is to reject merge commits, a command similar to
> > > “git log --pretty=oneline | wc -l” gives something that is very
> > 
> > git rev-list HEAD | wc -l
> 
> That is still in the 1.3 seconds range, git rev-list --count HEAD | wc -l
> is in the 1 seconds range user time.

You can store the output of

  git rev-list <branch>

somewhere, this should be fully static (on official branches).  Use
--reverse if you want extra convenience ;-)


$ git rev-list --reverse $BRANCH | grep -n $HASH | sed 's/:.*//'


Segher

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On May 17, 2019, at 3:22 PM, Martin Liška <mliska@suse.cz> wrote:
> 
> On 5/17/19 1:06 AM, Joseph Myers wrote:
>> That repository 
>> represents what I consider the collaboratively built consensus on such 
>> things as the desired author map (including handling of the ambiguous 
>> author name), which directories represent branches and tags, and what tags 
>> should be kept or removed - but building up such a consensus and keeping 
> 
> About the map. I agree with Richard that we should do best approach and not
> to fully reconstruct history of people who has switched email address multi
> times. I cloned git://thyrsus.com/repositories/gcc-conversion.git and made
> a clean up:
> 
> - for logins with duplicite emails I chose the latest one used on gcc-patches mailing list
> - comments were removed
> - a few entries contained timezone and I stripped that
> 
> Final version of the map can be seen here:
> https://github.com/marxin/gcc-git-conversion/blob/cleanup/gcc.map
> 
> @Maxim: would it be possible to update your script so that it will use:
> --authors-file=gcc.map ?

Should not be a problem.  I'll try that.

> 
> Is it desired for the transition to use the author map? Do we want it?

IIUC, the downside is that converted repo will not match current git mirror unless we do log re-writing, which would add extra info on the side.

--
Maxim Kuvyrkov
www.linaro.org

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Martin Liška]

On 5/17/19 4:59 PM, Maxim Kuvyrkov wrote:
>> On May 17, 2019, at 3:22 PM, Martin Liška <mliska@suse.cz> wrote:
>>
>> On 5/17/19 1:06 AM, Joseph Myers wrote:
>>> That repository
>>> represents what I consider the collaboratively built consensus on such
>>> things as the desired author map (including handling of the ambiguous
>>> author name), which directories represent branches and tags, and what tags
>>> should be kept or removed - but building up such a consensus and keeping
>>
>> About the map. I agree with Richard that we should do best approach and not
>> to fully reconstruct history of people who has switched email address multi
>> times. I cloned git://thyrsus.com/repositories/gcc-conversion.git and made
>> a clean up:
>>
>> - for logins with duplicite emails I chose the latest one used on gcc-patches mailing list
>> - comments were removed
>> - a few entries contained timezone and I stripped that
>>
>> Final version of the map can be seen here:
>> https://github.com/marxin/gcc-git-conversion/blob/cleanup/gcc.map
>>
>> @Maxim: would it be possible to update your script so that it will use:
>> --authors-file=gcc.map ?
> 
> Should not be a problem.  I'll try that.
> 
>>
>> Is it desired for the transition to use the author map? Do we want it?
> 
> IIUC, the downside is that converted repo will not match current git mirror unless we do log re-writing, which would add extra info on the side.

Just to be clear: I don't insist on the authors map and I see @Segher is strongly against (@Richard probably as well).
I'm just saying that we have a pretty compete authors map and we can liberally decide whether to use it or not
(with all pros and cons).

Martin

> 
> --
> Maxim Kuvyrkov
> www.linaro.org
> 

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On May 17, 2019, at 2:06 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> On Tue, 14 May 2019, Maxim Kuvyrkov wrote:
> 
>> The scripts convert svn history branch by branch.  They rely on git-svn 
>> on convert individual branches.  Git-svn is a good tool for converting 
>> individual branches.  It is, however, either very slow at converting the 
>> entire GCC repo, or goes into infinite loop.
> 
> I think git-svn is in fact a bad tool for repository conversion when the 
> history is nontrivial (for the reasons that have been discussed at length 
> in the past),

I agree with this.  However, with git -- we don't need to force ourselves to convert the whole history in one go; git-svn seems to be doing a good job at converting branch at a time.

> and we should convert with reposurgeon.

If reposurgeon works -- great, let's convert with it.  It's good to have two independent tools so that we can compare and sanity check the results; from the top of my head:
1. number of merges should match on all branches,
2. changed files should match for all revisions.

What I want to avoid is delaying the switch to git.

> 
> ESR, can you give an update on the status of the conversion with 
> reposurgeon?  You said "another serious attack on the repository 
> conversion is probably about two months out" in 
> <https://gcc.gnu.org/ml/gcc/2018-12/msg00112.html>.  Is it on target to be 
> done by the time of the GNU Tools Cauldron in Montreal in September?
> 
> And, could you bring git://thyrsus.com/repositories/gcc-conversion.git up 
> to date with changes since Jan 2018, or push the latest version of that 
> repository to some other public hosting location?  That repository 
> represents what I consider the collaboratively built consensus on such 
> things as the desired author map (including handling of the ambiguous 
> author name), which directories represent branches and tags, and what tags 
> should be kept or removed - but building up such a consensus and keeping 
> it up to date over time (for new committers etc.) requires that the public 
> repository actually reflects the latest version of the conversion 
> machinery, day by day as the consensus develops.  Review of that 
> repository will be important for reviewing the details of whether the 
> conversion is being done as desired - the details of the machinery will 
> help suggest things to spot-check in a converted repository.



--
Maxim Kuvyrkov
www.linaro.org

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Jason Merrill]

On Tue, May 14, 2019 at 12:11 PM Maxim Kuvyrkov
<maxim.kuvyrkov@linaro.org> wrote:
>
> This patch adds scripts to contrib/ to migrate full history of GCC's subversion repository to git.  My hope is that these scripts will finally allow GCC project to migrate to Git.

Thanks for looking into this.  My feeling has been that, if we give up
on reposurgeon, there's no need to start a new conversion at all: we
can just switch the current mirror over to being the primary
repository with some minor surgery (e.g. using git filter-branch to
fix subdirectory branches).  That approach will produce the least
disruption in the workflows of people already using it.  Do you see a
problem with this?

Jason

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On May 17, 2019, at 4:07 PM, Jason Merrill <jason@redhat.com> wrote:
> 
> On Tue, May 14, 2019 at 12:11 PM Maxim Kuvyrkov
> <maxim.kuvyrkov@linaro.org> wrote:
>> 
>> This patch adds scripts to contrib/ to migrate full history of GCC's subversion repository to git.  My hope is that these scripts will finally allow GCC project to migrate to Git.
> 
> Thanks for looking into this.  My feeling has been that, if we give up
> on reposurgeon, there's no need to start a new conversion at all: we
> can just switch the current mirror over to being the primary
> repository with some minor surgery (e.g. using git filter-branch to
> fix subdirectory branches).  That approach will produce the least
> disruption in the workflows of people already using it.  Do you see a
> problem with this?

No technical problem.  The scripts start with the existing git mirror and only convert the parts that are not present in it.  FWIW, the scripts can start with a bare repo, but that would take longer time.

It is a good idea to run a test conversion without using existing mirror as cache to confirm that there are no discrepancies in repos produced by old and new versions of git-svn.

However, if the community decides that we want use author maps, then, iiuc, the new repo would not be compatible with the existing mirror.

--
Maxim Kuvyrkov
www.linaro.org

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Joseph Myers]

On Fri, 17 May 2019, Jason Merrill wrote:

> Thanks for looking into this.  My feeling has been that, if we give up
> on reposurgeon, there's no need to start a new conversion at all: we
> can just switch the current mirror over to being the primary
> repository with some minor surgery (e.g. using git filter-branch to
> fix subdirectory branches).  That approach will produce the least
> disruption in the workflows of people already using it.  Do you see a
> problem with this?

I'd expect more major surgery (in particular remapping authors) if 
reposurgeon fails.

I don't expect reposurgeon to fail.  I expect even the python version of 
reposurgeon would work, with a few bug fixes - it's just that with 
day-long test cycles and hours to load a GCC repository dump into the 
python version, it's very hard actually to debug subtle issues with 
handling Subversion dumps to find out what those bugs are and fix them, 
which is where the Go version should help once finished, by being 
substantially faster.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

Hi Everyone,

What can I say, I was too optimistic about how easy it would be to convert GCC's svn repo to git one branch at a time.  After 2 more weeks and several re-writes of the scripts I now know more about GCC's svn history than I would ever wanted.

The prize for most complicated branch history goes to /branches/ibm/* .  It has merges, it has re-creation branches from /trunk and even an accidental deletion of all of IBM's branches.

The version of scripts I'm testing right now seems to deal with all of that.

Also, to avoid controversy -- I'm working on these scripts to satisfy my own curiosity, and to give GCC community another option to choose from for the final migration.  If by end of Summer 2019 we have 2-3 git repos to choose from, then we are likely to push GCC [kicking and screaming] into 2010's by the end of this decade.

--
Maxim Kuvyrkov
www.linaro.org



> On May 14, 2019, at 7:11 PM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
> 
> This patch adds scripts to contrib/ to migrate full history of GCC's subversion repository to git.  My hope is that these scripts will finally allow GCC project to migrate to Git.
> 
> The result of the conversion is at https://github.com/maxim-kuvyrkov/gcc/branches/all .  Branches with "@rev" suffixes represent branch points.  The conversion is still running, so not all branches may appear right away.
> 
> The scripts are not specific to GCC repo and are usable for other projects.  In particular, they should be able to convert downstream GCC svn repos.
> 
> The scripts convert svn history branch by branch.  They rely on git-svn on convert individual branches.  Git-svn is a good tool for converting individual branches.  It is, however, either very slow at converting the entire GCC repo, or goes into infinite loop.
> 
> There are 3 scripts:
> 
> - svn-git-repo.sh: top level script to convert entire repo or a part of it (e.g., branches/),
> - svn-list-branches.sh: helper script to output branches and their parents in bottom-up order,
> - svn-git-branch.sh: helper script to convert a single branch.
> 
> Whenever possible, svn-git-branch.sh uses existing git branches as caches.
> 
> What are your questions and comments?
> 
> The attached is cleaned up version, which hasn't been fully tested yet; typos and other silly mistakes are likely.  OK to commit after testing?
> 
> --
> Maxim Kuvyrkov
> www.linaro.org
> 
> 
> <0001-Contrib-SVN-Git-conversion-scripts.patch>

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

Hi Everyone,

I've been swamped with other projects for most of June, which gave me time to digest all the feedback I've got on GCC's conversion from SVN to Git.

The scripts have heavily evolved from the initial version posted here.  They have become fairly generic in that they have no implied knowledge about GCC's repo structure.  Due to this I no longer plan to merge them into GCC tree, but rather publish as a separate project on github.  For now, you can track the current [hairy] version at https://review.linaro.org/c/toolchain/gcc/+/31416 .

The initial version of scripts used heuristics to construct branch tree, which turned out to be error-prone.  The current version parse entire history of SVN repo to detect all trees that start at /trunk@1.  Therefore all branches in the converted repo converge to the same parent at the beginning of their histories.

As far as GCC conversion goes, below is what I plan to do and what not to do.  This is based on comments from everyone in this thread:

1. Construct GCC's git repo from SVN using same settings as current git mirror.
2. Compare the resulting git repo with current GCC mirror -- they should match on the commit hash level for trunk, branches/gcc-*-branch, and other "normal" branches.
3. Investigate any differences between converted GCC repo and current GCC mirror.  These can be due to bugs in git-svn or other misconfigurations.
4. Import git-only branches from current GCC mirror.
5. Publish this "raw" repo for community to sanity-check its contents.
6. Re-write history of all branches -- converted from svn and git-only -- see note below [*].
7. Publish this "pretty" repo for community to sanity-check its contents.
8. Update both "raw" and "pretty" repos daily with new commits
9. Fix problems in the "raw" and "pretty" repos as they reported by the community.

Once these steps are done, the community could switch from SVN to git by disabling commits to SVN, waiting for final history to be absorbed by the "pretty" repo, and deploying the git repo as the official repo.

[*] Note on branch re-writing:
During svn->git conversion we have an opportunity to correct some of the artifacts of current git mirror:

a. Author and committer entries.  These are difficult to get right during git-svn import process because the tool gives only SVN committer ID without much else.  We could do much better by matching SVN committer ID with person's name in the map file, and then searching for person's current-at-the-time email address in the commit diff.  I.e., mkuvyrkov -> Maxim Kuvyrkov -> [changelog from 2010's commit] -> maxim@codesourcery.com .

b. Re-write tags/ branches into annotated tags.  Note that tags/* are included into history of several branches via merge or copy commits, so we would need to re-write history to have proper references to annotated tag commits in the histories of such branches.

c. Since we are re-writing history anyway, it would be nice to convert "svn-git: svn+ssh://" tags to "svn-git: https://".  We are sure to retain publicly-visible svn repo accessible via https://, but not as likely to retain svn+ssh:// interface.

Which of these will make into the final repo is for community to decide.

Regards,

--
Maxim Kuvyrkov
www.linaro.org



> On May 28, 2019, at 1:31 PM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
> 
> Hi Everyone,
> 
> What can I say, I was too optimistic about how easy it would be to convert GCC's svn repo to git one branch at a time.  After 2 more weeks and several re-writes of the scripts I now know more about GCC's svn history than I would ever wanted.
> 
> The prize for most complicated branch history goes to /branches/ibm/* .  It has merges, it has re-creation branches from /trunk and even an accidental deletion of all of IBM's branches.
> 
> The version of scripts I'm testing right now seems to deal with all of that.
> 
> Also, to avoid controversy -- I'm working on these scripts to satisfy my own curiosity, and to give GCC community another option to choose from for the final migration.  If by end of Summer 2019 we have 2-3 git repos to choose from, then we are likely to push GCC [kicking and screaming] into 2010's by the end of this decade.
> 
> --
> Maxim Kuvyrkov
> www.linaro.org
> 
> 
> 
>> On May 14, 2019, at 7:11 PM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
>> 
>> This patch adds scripts to contrib/ to migrate full history of GCC's subversion repository to git.  My hope is that these scripts will finally allow GCC project to migrate to Git.
>> 
>> The result of the conversion is at https://github.com/maxim-kuvyrkov/gcc/branches/all .  Branches with "@rev" suffixes represent branch points.  The conversion is still running, so not all branches may appear right away.
>> 
>> The scripts are not specific to GCC repo and are usable for other projects.  In particular, they should be able to convert downstream GCC svn repos.
>> 
>> The scripts convert svn history branch by branch.  They rely on git-svn on convert individual branches.  Git-svn is a good tool for converting individual branches.  It is, however, either very slow at converting the entire GCC repo, or goes into infinite loop.
>> 
>> There are 3 scripts:
>> 
>> - svn-git-repo.sh: top level script to convert entire repo or a part of it (e.g., branches/),
>> - svn-list-branches.sh: helper script to output branches and their parents in bottom-up order,
>> - svn-git-branch.sh: helper script to convert a single branch.
>> 
>> Whenever possible, svn-git-branch.sh uses existing git branches as caches.
>> 
>> What are your questions and comments?
>> 
>> The attached is cleaned up version, which hasn't been fully tested yet; typos and other silly mistakes are likely.  OK to commit after testing?
>> 
>> --
>> Maxim Kuvyrkov
>> www.linaro.org
>> 
>> 
>> <0001-Contrib-SVN-Git-conversion-scripts.patch>
> 

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Jason Merrill]

On Tue, Jul 16, 2019 at 12:18 PM Maxim Kuvyrkov
<maxim.kuvyrkov@linaro.org> wrote:
>
> Hi Everyone,
>
> I've been swamped with other projects for most of June, which gave me time to digest all the feedback I've got on GCC's conversion from SVN to Git.
>
> The scripts have heavily evolved from the initial version posted here.  They have become fairly generic in that they have no implied knowledge about GCC's repo structure.  Due to this I no longer plan to merge them into GCC tree, but rather publish as a separate project on github.  For now, you can track the current [hairy] version at https://review.linaro.org/c/toolchain/gcc/+/31416 .
>
> The initial version of scripts used heuristics to construct branch tree, which turned out to be error-prone.  The current version parse entire history of SVN repo to detect all trees that start at /trunk@1.  Therefore all branches in the converted repo converge to the same parent at the beginning of their histories.
>
> As far as GCC conversion goes, below is what I plan to do and what not to do.  This is based on comments from everyone in this thread:
>
> 1. Construct GCC's git repo from SVN using same settings as current git mirror.
> 2. Compare the resulting git repo with current GCC mirror -- they should match on the commit hash level for trunk, branches/gcc-*-branch, and other "normal" branches.
> 3. Investigate any differences between converted GCC repo and current GCC mirror.  These can be due to bugs in git-svn or other misconfigurations.
> 4. Import git-only branches from current GCC mirror.
> 5. Publish this "raw" repo for community to sanity-check its contents.

Why not start from the current mirror?  Perhaps a mirror of the mirror?

> 6. Re-write history of all branches -- converted from svn and git-only -- see note below [*].
> 7. Publish this "pretty" repo for community to sanity-check its contents.
> 8. Update both "raw" and "pretty" repos daily with new commits
> 9. Fix problems in the "raw" and "pretty" repos as they reported by the community.
>
> Once these steps are done, the community could switch from SVN to git by disabling commits to SVN, waiting for final history to be absorbed by the "pretty" repo, and deploying the git repo as the official repo.
>
> [*] Note on branch re-writing:
> During svn->git conversion we have an opportunity to correct some of the artifacts of current git mirror:
>
> a. Author and committer entries.  These are difficult to get right during git-svn import process because the tool gives only SVN committer ID without much else.  We could do much better by matching SVN committer ID with person's name in the map file, and then searching for person's current-at-the-time email address in the commit diff.  I.e., mkuvyrkov -> Maxim Kuvyrkov -> [changelog from 2010's commit] -> maxim@codesourcery.com .

> c. Since we are re-writing history anyway, it would be nice to convert "svn-git: svn+ssh://" tags to "svn-git: https://".  We are sure to retain publicly-visible svn repo accessible via https://, but not as likely to retain svn+ssh:// interface.

I am moderately opposed to rewriting trunk and release branch history;
if we're using git-svn anyway, the benefit would have to be large to
outweigh the significant inconvenience to all current users of needing
to switch their local trees over to a new history.

> b. Re-write tags/ branches into annotated tags.  Note that tags/* are included into history of several branches via merge or copy commits, so we would need to re-write history to have proper references to annotated tag commits in the histories of such branches.

Missing tags is definitely something to fix about the current mirror.
I don't think we need to worry about inserting them into branch
history.

We should definitely also rewrite vendor/subdirectory branches into
multiple branches.

Jason

> Which of these will make into the final repo is for community to decide.
>
> Regards,
>
> --
> Maxim Kuvyrkov
> www.linaro.org
>
>
>
> > On May 28, 2019, at 1:31 PM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
> >
> > Hi Everyone,
> >
> > What can I say, I was too optimistic about how easy it would be to convert GCC's svn repo to git one branch at a time.  After 2 more weeks and several re-writes of the scripts I now know more about GCC's svn history than I would ever wanted.
> >
> > The prize for most complicated branch history goes to /branches/ibm/* .  It has merges, it has re-creation branches from /trunk and even an accidental deletion of all of IBM's branches.
> >
> > The version of scripts I'm testing right now seems to deal with all of that.
> >
> > Also, to avoid controversy -- I'm working on these scripts to satisfy my own curiosity, and to give GCC community another option to choose from for the final migration.  If by end of Summer 2019 we have 2-3 git repos to choose from, then we are likely to push GCC [kicking and screaming] into 2010's by the end of this decade.
> >
> > --
> > Maxim Kuvyrkov
> > www.linaro.org
> >
> >
> >
> >> On May 14, 2019, at 7:11 PM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
> >>
> >> This patch adds scripts to contrib/ to migrate full history of GCC's subversion repository to git.  My hope is that these scripts will finally allow GCC project to migrate to Git.
> >>
> >> The result of the conversion is at https://github.com/maxim-kuvyrkov/gcc/branches/all .  Branches with "@rev" suffixes represent branch points.  The conversion is still running, so not all branches may appear right away.
> >>
> >> The scripts are not specific to GCC repo and are usable for other projects.  In particular, they should be able to convert downstream GCC svn repos.
> >>
> >> The scripts convert svn history branch by branch.  They rely on git-svn on convert individual branches.  Git-svn is a good tool for converting individual branches.  It is, however, either very slow at converting the entire GCC repo, or goes into infinite loop.
> >>
> >> There are 3 scripts:
> >>
> >> - svn-git-repo.sh: top level script to convert entire repo or a part of it (e.g., branches/),
> >> - svn-list-branches.sh: helper script to output branches and their parents in bottom-up order,
> >> - svn-git-branch.sh: helper script to convert a single branch.
> >>
> >> Whenever possible, svn-git-branch.sh uses existing git branches as caches.
> >>
> >> What are your questions and comments?
> >>
> >> The attached is cleaned up version, which hasn't been fully tested yet; typos and other silly mistakes are likely.  OK to commit after testing?
> >>
> >> --
> >> Maxim Kuvyrkov
> >> www.linaro.org
> >>
> >>
> >> <0001-Contrib-SVN-Git-conversion-scripts.patch>
> >
>

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On Jul 16, 2019, at 3:34 PM, Jason Merrill <jason@redhat.com> wrote:
> 
> On Tue, Jul 16, 2019 at 12:18 PM Maxim Kuvyrkov
> <maxim.kuvyrkov@linaro.org> wrote:
>> 
>> Hi Everyone,
>> 
>> I've been swamped with other projects for most of June, which gave me time to digest all the feedback I've got on GCC's conversion from SVN to Git.
>> 
>> The scripts have heavily evolved from the initial version posted here.  They have become fairly generic in that they have no implied knowledge about GCC's repo structure.  Due to this I no longer plan to merge them into GCC tree, but rather publish as a separate project on github.  For now, you can track the current [hairy] version at https://review.linaro.org/c/toolchain/gcc/+/31416 .
>> 
>> The initial version of scripts used heuristics to construct branch tree, which turned out to be error-prone.  The current version parse entire history of SVN repo to detect all trees that start at /trunk@1.  Therefore all branches in the converted repo converge to the same parent at the beginning of their histories.
>> 
>> As far as GCC conversion goes, below is what I plan to do and what not to do.  This is based on comments from everyone in this thread:
>> 
>> 1. Construct GCC's git repo from SVN using same settings as current git mirror.
>> 2. Compare the resulting git repo with current GCC mirror -- they should match on the commit hash level for trunk, branches/gcc-*-branch, and other "normal" branches.
>> 3. Investigate any differences between converted GCC repo and current GCC mirror.  These can be due to bugs in git-svn or other misconfigurations.
>> 4. Import git-only branches from current GCC mirror.
>> 5. Publish this "raw" repo for community to sanity-check its contents.
> 
> Why not start from the current mirror?  Perhaps a mirror of the mirror?

To check that git-svn is self-consistent and generates same commits now as it was several years ago when you setup the current mirror.  

> 
>> 6. Re-write history of all branches -- converted from svn and git-only -- see note below [*].
>> 7. Publish this "pretty" repo for community to sanity-check its contents.
>> 8. Update both "raw" and "pretty" repos daily with new commits
>> 9. Fix problems in the "raw" and "pretty" repos as they reported by the community.
>> 
>> Once these steps are done, the community could switch from SVN to git by disabling commits to SVN, waiting for final history to be absorbed by the "pretty" repo, and deploying the git repo as the official repo.
>> 
>> [*] Note on branch re-writing:
>> During svn->git conversion we have an opportunity to correct some of the artifacts of current git mirror:
>> 
>> a. Author and committer entries.  These are difficult to get right during git-svn import process because the tool gives only SVN committer ID without much else.  We could do much better by matching SVN committer ID with person's name in the map file, and then searching for person's current-at-the-time email address in the commit diff.  I.e., mkuvyrkov -> Maxim Kuvyrkov -> [changelog from 2010's commit] -> maxim@codesourcery.com .
> 
>> c. Since we are re-writing history anyway, it would be nice to convert "svn-git: svn+ssh://" tags to "svn-git: https://".  We are sure to retain publicly-visible svn repo accessible via https://, but not as likely to retain svn+ssh:// interface.
> 
> I am moderately opposed to rewriting trunk and release branch history;
> if we're using git-svn anyway, the benefit would have to be large to
> outweigh the significant inconvenience to all current users of needing
> to switch their local trees over to a new history.

I mostly agree with your point.  My thinking is that the git mirror was never official canonical GCC repo, and if we ever want to get better author/committer identities -- this is our chance.

> 
>> b. Re-write tags/ branches into annotated tags.  Note that tags/* are included into history of several branches via merge or copy commits, so we would need to re-write history to have proper references to annotated tag commits in the histories of such branches.
> 
> Missing tags is definitely something to fix about the current mirror.
> I don't think we need to worry about inserting them into branch
> history.

If we don't do this then "git branch -a --contains some/tag" will not work correctly.

> 
> We should definitely also rewrite vendor/subdirectory branches into
> multiple branches.

Vendor and subdirectory branches are properly handled by the scripts.  I wonder whether re-writing them using tree-filters would produce same result as git-svn conversions I'm doing.

--
Maxim Kuvyrkov
www.linaro.org


> 
>> Which of these will make into the final repo is for community to decide.
>> 
>> Regards,
>> 
>> --
>> Maxim Kuvyrkov
>> www.linaro.org
>> 
>> 
>> 
>>> On May 28, 2019, at 1:31 PM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
>>> 
>>> Hi Everyone,
>>> 
>>> What can I say, I was too optimistic about how easy it would be to convert GCC's svn repo to git one branch at a time.  After 2 more weeks and several re-writes of the scripts I now know more about GCC's svn history than I would ever wanted.
>>> 
>>> The prize for most complicated branch history goes to /branches/ibm/* .  It has merges, it has re-creation branches from /trunk and even an accidental deletion of all of IBM's branches.
>>> 
>>> The version of scripts I'm testing right now seems to deal with all of that.
>>> 
>>> Also, to avoid controversy -- I'm working on these scripts to satisfy my own curiosity, and to give GCC community another option to choose from for the final migration.  If by end of Summer 2019 we have 2-3 git repos to choose from, then we are likely to push GCC [kicking and screaming] into 2010's by the end of this decade.
>>> 
>>> --
>>> Maxim Kuvyrkov
>>> www.linaro.org
>>> 
>>> 
>>> 
>>>> On May 14, 2019, at 7:11 PM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
>>>> 
>>>> This patch adds scripts to contrib/ to migrate full history of GCC's subversion repository to git.  My hope is that these scripts will finally allow GCC project to migrate to Git.
>>>> 
>>>> The result of the conversion is at https://github.com/maxim-kuvyrkov/gcc/branches/all . Branches with "@rev" suffixes represent branch points.  The conversion is still running, so not all branches may appear right away.
>>>> 
>>>> The scripts are not specific to GCC repo and are usable for other projects.  In particular, they should be able to convert downstream GCC svn repos.
>>>> 
>>>> The scripts convert svn history branch by branch.  They rely on git-svn on convert individual branches.  Git-svn is a good tool for converting individual branches.  It is, however, either very slow at converting the entire GCC repo, or goes into infinite loop.
>>>> 
>>>> There are 3 scripts:
>>>> 
>>>> - svn-git-repo.sh: top level script to convert entire repo or a part of it (e.g., branches/),
>>>> - svn-list-branches.sh: helper script to output branches and their parents in bottom-up order,
>>>> - svn-git-branch.sh: helper script to convert a single branch.
>>>> 
>>>> Whenever possible, svn-git-branch.sh uses existing git branches as caches.
>>>> 
>>>> What are your questions and comments?
>>>> 
>>>> The attached is cleaned up version, which hasn't been fully tested yet; typos and other silly mistakes are likely.  OK to commit after testing?
>>>> 
>>>> --
>>>> Maxim Kuvyrkov
>>>> www.linaro.org
>>>> 
>>>> 
>>>> <0001-Contrib-SVN-Git-conversion-scripts.patch>

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On Jul 16, 2019, at 5:14 PM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
> 
>> On Jul 16, 2019, at 3:34 PM, Jason Merrill <jason@redhat.com> wrote:
>> 
...
>> 
>>> b. Re-write tags/ branches into annotated tags.  Note that tags/* are included into history of several branches via merge or copy commits, so we would need to re-write history to have proper references to annotated tag commits in the histories of such branches.
>> 
>> Missing tags is definitely something to fix about the current mirror.
>> I don't think we need to worry about inserting them into branch
>> history.
> 
> If we don't do this then "git branch -a --contains some/tag" will not work correctly.

I was wrong here.  Git tag objects (annotated tags) cannot appear in branch history because they are resolved to the commits they are pointing to.  Only commit objects can appear in branch history.

This makes conversion of tags much simpler, since [annotated] tags cannot affect history branches.

Regards,

--
Maxim Kuvyrkov
www.linaro.org

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On Jul 16, 2019, at 5:14 PM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
> 
>> On Jul 16, 2019, at 3:34 PM, Jason Merrill <jason@redhat.com> wrote:
>> 
>> On Tue, Jul 16, 2019 at 12:18 PM Maxim Kuvyrkov
>> <maxim.kuvyrkov@linaro.org> wrote:
>>> 
>>> Hi Everyone,
>>> 
>>> I've been swamped with other projects for most of June, which gave me time to digest all the feedback I've got on GCC's conversion from SVN to Git.
>>> 
>>> The scripts have heavily evolved from the initial version posted here.  They have become fairly generic in that they have no implied knowledge about GCC's repo structure.  Due to this I no longer plan to merge them into GCC tree, but rather publish as a separate project on github.  For now, you can track the current [hairy] version at https://review.linaro.org/c/toolchain/gcc/+/31416 .
>>> 
>>> The initial version of scripts used heuristics to construct branch tree, which turned out to be error-prone.  The current version parse entire history of SVN repo to detect all trees that start at /trunk@1.  Therefore all branches in the converted repo converge to the same parent at the beginning of their histories.
>>> 
>>> As far as GCC conversion goes, below is what I plan to do and what not to do.  This is based on comments from everyone in this thread:
>>> 
>>> 1. Construct GCC's git repo from SVN using same settings as current git mirror.
>>> 2. Compare the resulting git repo with current GCC mirror -- they should match on the commit hash level for trunk, branches/gcc-*-branch, and other "normal" branches.
>>> 3. Investigate any differences between converted GCC repo and current GCC mirror.  These can be due to bugs in git-svn or other misconfigurations.
>>> 4. Import git-only branches from current GCC mirror.
>>> 5. Publish this "raw" repo for community to sanity-check its contents.
>> 
>> Why not start from the current mirror?  Perhaps a mirror of the mirror?
> 
> To check that git-svn is self-consistent and generates same commits now as it was several years ago when you setup the current mirror.  

Unfortunately, current mirror does not and could not account for rewrites of SVN commit log messages.  For trunk the histories of diverge in 2008 due to commit message change of r138154.  This is not a single occurrence; I've compared histories only of trunk and gcc-6-branch, and both had commit message change (for gcc-6-branch see r259978).

It's up to the community is to weigh pros and cons of re-using existing GCC mirror as conversion base vs regenerating history from scratch:

Pros of using GCC mirror:
+ No need to rebase public git-only branches
+ No need to rebase private branches
+ No need to rebase current clones, checkouts, work-in-progress trees

Cons of using GCC mirror:
- Poor author / committer IDs (this breaks patch statistics software)
- Several commit messages will not be the current "fixed" version

Thoughts?

--
Maxim Kuvyrkov
www.linaro.org

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Jason Merrill]

On Mon, Jul 22, 2019 at 5:05 AM Maxim Kuvyrkov
<maxim.kuvyrkov@linaro.org> wrote:
>
> > On Jul 16, 2019, at 5:14 PM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
> >
> >> On Jul 16, 2019, at 3:34 PM, Jason Merrill <jason@redhat.com> wrote:
> >>
> >> On Tue, Jul 16, 2019 at 12:18 PM Maxim Kuvyrkov
> >> <maxim.kuvyrkov@linaro.org> wrote:
> >>>
> >>> Hi Everyone,
> >>>
> >>> I've been swamped with other projects for most of June, which gave me time to digest all the feedback I've got on GCC's conversion from SVN to Git.
> >>>
> >>> The scripts have heavily evolved from the initial version posted here.  They have become fairly generic in that they have no implied knowledge about GCC's repo structure.  Due to this I no longer plan to merge them into GCC tree, but rather publish as a separate project on github.  For now, you can track the current [hairy] version at https://review.linaro.org/c/toolchain/gcc/+/31416 .
> >>>
> >>> The initial version of scripts used heuristics to construct branch tree, which turned out to be error-prone.  The current version parse entire history of SVN repo to detect all trees that start at /trunk@1.  Therefore all branches in the converted repo converge to the same parent at the beginning of their histories.
> >>>
> >>> As far as GCC conversion goes, below is what I plan to do and what not to do.  This is based on comments from everyone in this thread:
> >>>
> >>> 1. Construct GCC's git repo from SVN using same settings as current git mirror.
> >>> 2. Compare the resulting git repo with current GCC mirror -- they should match on the commit hash level for trunk, branches/gcc-*-branch, and other "normal" branches.
> >>> 3. Investigate any differences between converted GCC repo and current GCC mirror.  These can be due to bugs in git-svn or other misconfigurations.
> >>> 4. Import git-only branches from current GCC mirror.
> >>> 5. Publish this "raw" repo for community to sanity-check its contents.
> >>
> >> Why not start from the current mirror?  Perhaps a mirror of the mirror?
> >
> > To check that git-svn is self-consistent and generates same commits now as it was several years ago when you setup the current mirror.
>
> Unfortunately, current mirror does not and could not account for rewrites of SVN commit log messages.  For trunk the histories of diverge in 2008 due to commit message change of r138154.  This is not a single occurrence; I've compared histories only of trunk and gcc-6-branch, and both had commit message change (for gcc-6-branch see r259978).
>
> It's up to the community is to weigh pros and cons of re-using existing GCC mirror as conversion base vs regenerating history from scratch:
>
> Pros of using GCC mirror:
> + No need to rebase public git-only branches
> + No need to rebase private branches
> + No need to rebase current clones, checkouts, work-in-progress trees
>
> Cons of using GCC mirror:
> - Poor author / committer IDs (this breaks patch statistics software)
> - Several commit messages will not be the current "fixed" version
>
> Thoughts?

I'm still inclined to stick with the mirror.  I would expect patch
statistics software to be able to be taught about multiple addresses
for the same person.

Jason

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On Aug 1, 2019, at 11:43 PM, Jason Merrill <jason@redhat.com> wrote:
> 
> On Mon, Jul 22, 2019 at 5:05 AM Maxim Kuvyrkov
> <maxim.kuvyrkov@linaro.org> wrote:
>> 
>>> On Jul 16, 2019, at 5:14 PM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
>>> 
>>>> On Jul 16, 2019, at 3:34 PM, Jason Merrill <jason@redhat.com> wrote:
>>>> 
>>>> On Tue, Jul 16, 2019 at 12:18 PM Maxim Kuvyrkov
>>>> <maxim.kuvyrkov@linaro.org> wrote:
>>>>> 
>>>>> Hi Everyone,
>>>>> 
>>>>> I've been swamped with other projects for most of June, which gave me time to digest all the feedback I've got on GCC's conversion from SVN to Git.
>>>>> 
>>>>> The scripts have heavily evolved from the initial version posted here.  They have become fairly generic in that they have no implied knowledge about GCC's repo structure.  Due to this I no longer plan to merge them into GCC tree, but rather publish as a separate project on github.  For now, you can track the current [hairy] version at https://review.linaro.org/c/toolchain/gcc/+/31416 .
>>>>> 
>>>>> The initial version of scripts used heuristics to construct branch tree, which turned out to be error-prone.  The current version parse entire history of SVN repo to detect all trees that start at /trunk@1.  Therefore all branches in the converted repo converge to the same parent at the beginning of their histories.
>>>>> 
>>>>> As far as GCC conversion goes, below is what I plan to do and what not to do.  This is based on comments from everyone in this thread:
>>>>> 
>>>>> 1. Construct GCC's git repo from SVN using same settings as current git mirror.
>>>>> 2. Compare the resulting git repo with current GCC mirror -- they should match on the commit hash level for trunk, branches/gcc-*-branch, and other "normal" branches.
>>>>> 3. Investigate any differences between converted GCC repo and current GCC mirror. These can be due to bugs in git-svn or other misconfigurations.
>>>>> 4. Import git-only branches from current GCC mirror.
>>>>> 5. Publish this "raw" repo for community to sanity-check its contents.
>>>> 
>>>> Why not start from the current mirror?  Perhaps a mirror of the mirror?
>>> 
>>> To check that git-svn is self-consistent and generates same commits now as it was several years ago when you setup the current mirror.
>> 
>> Unfortunately, current mirror does not and could not account for rewrites of SVN commit log messages.  For trunk the histories of diverge in 2008 due to commit message change of r138154.  This is not a single occurrence; I've compared histories only of trunk and gcc-6-branch, and both had commit message change (for gcc-6-branch see r259978).
>> 
>> It's up to the community is to weigh pros and cons of re-using existing GCC mirror as conversion base vs regenerating history from scratch:
>> 
>> Pros of using GCC mirror:
>> + No need to rebase public git-only branches
>> + No need to rebase private branches
>> + No need to rebase current clones, checkouts, work-in-progress trees
>> 
>> Cons of using GCC mirror:
>> - Poor author / committer IDs (this breaks patch statistics software)
>> - Several commit messages will not be the current "fixed" version
>> 
>> Thoughts?
> 
> I'm still inclined to stick with the mirror.  I would expect patch
> statistics software to be able to be taught about multiple addresses
> for the same person.

Patch tracking software breaks on emails like <fxcoudert@138bc75d-0d04-0410-961f-82ee72b054a4> , where 38bc75d-0d04-0410-961f-82ee72b054a4 is not a reasonable domain name.

For completeness, I'll generate and upload a repo based on current mirror with all branches and tags converted.

In the end, I don't care much to which version of the repo we switch, as long as we switch.

--
Maxim Kuvyrkov
www.linaro.org

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Richard Biener]

On Fri, Aug 2, 2019 at 10:41 AM Maxim Kuvyrkov
<maxim.kuvyrkov@linaro.org> wrote:
>
> > On Aug 1, 2019, at 11:43 PM, Jason Merrill <jason@redhat.com> wrote:
> >
> > On Mon, Jul 22, 2019 at 5:05 AM Maxim Kuvyrkov
> > <maxim.kuvyrkov@linaro.org> wrote:
> >>
> >>> On Jul 16, 2019, at 5:14 PM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
> >>>
> >>>> On Jul 16, 2019, at 3:34 PM, Jason Merrill <jason@redhat.com> wrote:
> >>>>
> >>>> On Tue, Jul 16, 2019 at 12:18 PM Maxim Kuvyrkov
> >>>> <maxim.kuvyrkov@linaro.org> wrote:
> >>>>>
> >>>>> Hi Everyone,
> >>>>>
> >>>>> I've been swamped with other projects for most of June, which gave me time to digest all the feedback I've got on GCC's conversion from SVN to Git.
> >>>>>
> >>>>> The scripts have heavily evolved from the initial version posted here.  They have become fairly generic in that they have no implied knowledge about GCC's repo structure.  Due to this I no longer plan to merge them into GCC tree, but rather publish as a separate project on github.  For now, you can track the current [hairy] version at https://review.linaro.org/c/toolchain/gcc/+/31416 .
> >>>>>
> >>>>> The initial version of scripts used heuristics to construct branch tree, which turned out to be error-prone.  The current version parse entire history of SVN repo to detect all trees that start at /trunk@1.  Therefore all branches in the converted repo converge to the same parent at the beginning of their histories.
> >>>>>
> >>>>> As far as GCC conversion goes, below is what I plan to do and what not to do.  This is based on comments from everyone in this thread:
> >>>>>
> >>>>> 1. Construct GCC's git repo from SVN using same settings as current git mirror.
> >>>>> 2. Compare the resulting git repo with current GCC mirror -- they should match on the commit hash level for trunk, branches/gcc-*-branch, and other "normal" branches.
> >>>>> 3. Investigate any differences between converted GCC repo and current GCC mirror. These can be due to bugs in git-svn or other misconfigurations.
> >>>>> 4. Import git-only branches from current GCC mirror.
> >>>>> 5. Publish this "raw" repo for community to sanity-check its contents.
> >>>>
> >>>> Why not start from the current mirror?  Perhaps a mirror of the mirror?
> >>>
> >>> To check that git-svn is self-consistent and generates same commits now as it was several years ago when you setup the current mirror.
> >>
> >> Unfortunately, current mirror does not and could not account for rewrites of SVN commit log messages.  For trunk the histories of diverge in 2008 due to commit message change of r138154.  This is not a single occurrence; I've compared histories only of trunk and gcc-6-branch, and both had commit message change (for gcc-6-branch see r259978).
> >>
> >> It's up to the community is to weigh pros and cons of re-using existing GCC mirror as conversion base vs regenerating history from scratch:
> >>
> >> Pros of using GCC mirror:
> >> + No need to rebase public git-only branches
> >> + No need to rebase private branches
> >> + No need to rebase current clones, checkouts, work-in-progress trees
> >>
> >> Cons of using GCC mirror:
> >> - Poor author / committer IDs (this breaks patch statistics software)
> >> - Several commit messages will not be the current "fixed" version
> >>
> >> Thoughts?
> >
> > I'm still inclined to stick with the mirror.  I would expect patch
> > statistics software to be able to be taught about multiple addresses
> > for the same person.
>
> Patch tracking software breaks on emails like <fxcoudert@138bc75d-0d04-0410-961f-82ee72b054a4> , where 38bc75d-0d04-0410-961f-82ee72b054a4 is not a reasonable domain name.
>
> For completeness, I'll generate and upload a repo based on current mirror with all branches and tags converted.
>
> In the end, I don't care much to which version of the repo we switch, as long as we switch.

I think that if we have something clearly better than the current
mirror we should use that.  rebasing might
be a hassle but git should make that reasonably easy - proper
instructions how to do that are of course
welcome (just add a new remote, adjust all local branches remote and
then rebase?).

Richard.

> --
> Maxim Kuvyrkov
> www.linaro.org
>
>
>
>

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Martin Liška]

On 8/2/19 10:41 AM, Maxim Kuvyrkov wrote:
> In the end, I don't care much to which version of the repo we switch, as long as we switch.

Hi Maxim.

I really appreciate that you've been working on that. Same as you I would like to see
any change that will lead to a git repository.

I have couple of questions about the upcoming Cauldron:

- Are you planning to attend?
- Would it be possible to prepare a voting during e.g. Steering Committee where
  we'll vote about transition options?
- Would it make sense to do an online questionnaire in advance in order
  to guess what's prevailing opinion?

If you are interested, I can help you?

Martin

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On Aug 2, 2019, at 1:26 PM, Martin Liška <mliska@suse.cz> wrote:
> 
> On 8/2/19 10:41 AM, Maxim Kuvyrkov wrote:
>> In the end, I don't care much to which version of the repo we switch, as long as we switch.
> 
> Hi Maxim.
> 
> I really appreciate that you've been working on that. Same as you I would like to see
> any change that will lead to a git repository.
> 
> I have couple of questions about the upcoming Cauldron:
> 
> - Are you planning to attend?

Unfortunately, I won't attend this time.

> - Would it be possible to prepare a voting during e.g. Steering Committee where
>  we'll vote about transition options?
> - Would it make sense to do an online questionnaire in advance in order
>  to guess what's prevailing opinion?
> 
> If you are interested, I can help you?

Let's organize an online survey now.  While most active GCC developers will attend Cauldron, many others will not, so we shouldn't rely on Cauldron to make any final decisions.

Martin, would you please organize the survey?

Regards,

--
Maxim Kuvyrkov
www.linaro.org

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Martin Liška]

On 8/2/19 12:54 PM, Maxim Kuvyrkov wrote:
>> On Aug 2, 2019, at 1:26 PM, Martin Liška <mliska@suse.cz> wrote:
>>
>> On 8/2/19 10:41 AM, Maxim Kuvyrkov wrote:
>>> In the end, I don't care much to which version of the repo we switch, as long as we switch.
>>
>> Hi Maxim.
>>
>> I really appreciate that you've been working on that. Same as you I would like to see
>> any change that will lead to a git repository.
>>
>> I have couple of questions about the upcoming Cauldron:
>>
>> - Are you planning to attend?
> 
> Unfortunately, I won't attend this time.

I see.

> 
>> - Would it be possible to prepare a voting during e.g. Steering Committee where
>>  we'll vote about transition options?
>> - Would it make sense to do an online questionnaire in advance in order
>>  to guess what's prevailing opinion?
>>
>> If you are interested, I can help you?
> 
> Let's organize an online survey now.  While most active GCC developers will attend Cauldron, many others will not, so we shouldn't rely on Cauldron to make any final decisions.

Sure, online is the best option as all active community members can vote.

> 
> Martin, would you please organize the survey?

Yes, but I haven't followed the discussion in recent weeks. Is the only question
whether we want the current GIT mirror or your rebased git repository?
Is Eric Raymond's transition still in play or not?
Are there any other sub-question regarding commit message format, git hooks, etc.
that will deserve a place in the questionnaire?

Thank,
Martin

> 
> Regards,
> 
> --
> Maxim Kuvyrkov
> www.linaro.org
> 

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Richard Biener]

On Fri, Aug 2, 2019 at 1:01 PM Martin Liška <mliska@suse.cz> wrote:
>
> On 8/2/19 12:54 PM, Maxim Kuvyrkov wrote:
> >> On Aug 2, 2019, at 1:26 PM, Martin Liška <mliska@suse.cz> wrote:
> >>
> >> On 8/2/19 10:41 AM, Maxim Kuvyrkov wrote:
> >>> In the end, I don't care much to which version of the repo we switch, as long as we switch.
> >>
> >> Hi Maxim.
> >>
> >> I really appreciate that you've been working on that. Same as you I would like to see
> >> any change that will lead to a git repository.
> >>
> >> I have couple of questions about the upcoming Cauldron:
> >>
> >> - Are you planning to attend?
> >
> > Unfortunately, I won't attend this time.
>
> I see.
>
> >
> >> - Would it be possible to prepare a voting during e.g. Steering Committee where
> >>  we'll vote about transition options?
> >> - Would it make sense to do an online questionnaire in advance in order
> >>  to guess what's prevailing opinion?
> >>
> >> If you are interested, I can help you?
> >
> > Let's organize an online survey now.  While most active GCC developers will attend Cauldron, many others will not, so we shouldn't rely on Cauldron to make any final decisions.
>
> Sure, online is the best option as all active community members can vote.
>
> >
> > Martin, would you please organize the survey?
>
> Yes, but I haven't followed the discussion in recent weeks. Is the only question
> whether we want the current GIT mirror or your rebased git repository?
> Is Eric Raymond's transition still in play or not?

1) Stay with SVN
2) Switch to the existing GIT mirror
3) Wait for ERS to complete his conversion to GIT
4) Use the existing new conversion to GIT fixing authors and commit messages
5) I don't care
6) I don't care as long as we switch to GIT

> Are there any other sub-question regarding commit message format, git hooks, etc.
> that will deserve a place in the questionnaire?

No, please do not make it unnecessarily complicated.  Maybe the questionaire
can include a free-form text field for more comments.

Btw, I do not believe we should do this kind of voting.  Who's eligible to vote?
Is the vote anonymous?  What happens when the majority (what is the majority?)
votes for option N?

IMHO voting is bike-shedding.

Those who do the work decide.  _They_ may ask questions _and_ decide whether
to listen to the answer.

Richard.

> Thank,
> Martin
>
> >
> > Regards,
> >
> > --
> > Maxim Kuvyrkov
> > www.linaro.org
> >
>

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Martin Liška]

On 8/2/19 1:06 PM, Richard Biener wrote:
> On Fri, Aug 2, 2019 at 1:01 PM Martin Liška <mliska@suse.cz> wrote:
>>
>> On 8/2/19 12:54 PM, Maxim Kuvyrkov wrote:
>>>> On Aug 2, 2019, at 1:26 PM, Martin Liška <mliska@suse.cz> wrote:
>>>>
>>>> On 8/2/19 10:41 AM, Maxim Kuvyrkov wrote:
>>>>> In the end, I don't care much to which version of the repo we switch, as long as we switch.
>>>>
>>>> Hi Maxim.
>>>>
>>>> I really appreciate that you've been working on that. Same as you I would like to see
>>>> any change that will lead to a git repository.
>>>>
>>>> I have couple of questions about the upcoming Cauldron:
>>>>
>>>> - Are you planning to attend?
>>>
>>> Unfortunately, I won't attend this time.
>>
>> I see.
>>
>>>
>>>> - Would it be possible to prepare a voting during e.g. Steering Committee where
>>>>  we'll vote about transition options?
>>>> - Would it make sense to do an online questionnaire in advance in order
>>>>  to guess what's prevailing opinion?
>>>>
>>>> If you are interested, I can help you?
>>>
>>> Let's organize an online survey now.  While most active GCC developers will attend Cauldron, many others will not, so we shouldn't rely on Cauldron to make any final decisions.
>>
>> Sure, online is the best option as all active community members can vote.
>>
>>>
>>> Martin, would you please organize the survey?
>>
>> Yes, but I haven't followed the discussion in recent weeks. Is the only question
>> whether we want the current GIT mirror or your rebased git repository?
>> Is Eric Raymond's transition still in play or not?
> 
> 1) Stay with SVN
> 2) Switch to the existing GIT mirror
> 3) Wait for ERS to complete his conversion to GIT
> 4) Use the existing new conversion to GIT fixing authors and commit messages
> 5) I don't care
> 6) I don't care as long as we switch to GIT
> 
>> Are there any other sub-question regarding commit message format, git hooks, etc.
>> that will deserve a place in the questionnaire?
> 
> No, please do not make it unnecessarily complicated.  Maybe the questionaire
> can include a free-form text field for more comments.
> 
> Btw, I do not believe we should do this kind of voting.  Who's eligible to vote?
> Is the vote anonymous?  What happens when the majority (what is the majority?)
> votes for option N?
> 
> IMHO voting is bike-shedding.
> 
> Those who do the work decide.  _They_ may ask questions _and_ decide whether
> to listen to the answer.
> 
> Richard.
> 
>> Thank,
>> Martin
>>
>>>
>>> Regards,
>>>
>>> --
>>> Maxim Kuvyrkov
>>> www.linaro.org
>>>
>>

So Richi is suggesting to finish all necessary for transition before we'll vote.
That should include bugzilla reporting script and maybe other git hooks?
Do we have a checklist of these? Jason?

Thanks,
Martin

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Jason Merrill]

On Fri, Aug 2, 2019 at 7:35 AM Martin Liška <mliska@suse.cz> wrote:
>
> On 8/2/19 1:06 PM, Richard Biener wrote:
> > On Fri, Aug 2, 2019 at 1:01 PM Martin Liška <mliska@suse.cz> wrote:
> >>
> >> On 8/2/19 12:54 PM, Maxim Kuvyrkov wrote:
> >>>> On Aug 2, 2019, at 1:26 PM, Martin Liška <mliska@suse.cz> wrote:
> >>>>
> >>>> On 8/2/19 10:41 AM, Maxim Kuvyrkov wrote:
> >>>>> In the end, I don't care much to which version of the repo we switch, as long as we switch.
> >>>>
> >>>> Hi Maxim.
> >>>>
> >>>> I really appreciate that you've been working on that. Same as you I would like to see
> >>>> any change that will lead to a git repository.
> >>>>
> >>>> I have couple of questions about the upcoming Cauldron:
> >>>>
> >>>> - Are you planning to attend?
> >>>
> >>> Unfortunately, I won't attend this time.
> >>
> >> I see.
> >>
> >>>
> >>>> - Would it be possible to prepare a voting during e.g. Steering Committee where
> >>>>  we'll vote about transition options?
> >>>> - Would it make sense to do an online questionnaire in advance in order
> >>>>  to guess what's prevailing opinion?
> >>>>
> >>>> If you are interested, I can help you?
> >>>
> >>> Let's organize an online survey now.  While most active GCC developers will attend Cauldron, many others will not, so we shouldn't rely on Cauldron to make any final decisions.
> >>
> >> Sure, online is the best option as all active community members can vote.
> >>
> >>>
> >>> Martin, would you please organize the survey?
> >>
> >> Yes, but I haven't followed the discussion in recent weeks. Is the only question
> >> whether we want the current GIT mirror or your rebased git repository?
> >> Is Eric Raymond's transition still in play or not?
> >
> > 1) Stay with SVN
> > 2) Switch to the existing GIT mirror
> > 3) Wait for ERS to complete his conversion to GIT
> > 4) Use the existing new conversion to GIT fixing authors and commit messages
> > 5) I don't care
> > 6) I don't care as long as we switch to GIT
> >
> >> Are there any other sub-question regarding commit message format, git hooks, etc.
> >> that will deserve a place in the questionnaire?
> >
> > No, please do not make it unnecessarily complicated.  Maybe the questionaire
> > can include a free-form text field for more comments.
> >
> > Btw, I do not believe we should do this kind of voting.  Who's eligible to vote?
> > Is the vote anonymous?  What happens when the majority (what is the majority?)
> > votes for option N?
> >
> > IMHO voting is bike-shedding.
> >
> > Those who do the work decide.  _They_ may ask questions _and_ decide whether
> > to listen to the answer.
> >
> > Richard.
> >
> >> Thank,
> >> Martin
> >>
> >>>
> >>> Regards,
> >>>
> >>> --
> >>> Maxim Kuvyrkov
> >>> www.linaro.org
> >>>
> >>
>
> So Richi is suggesting to finish all necessary for transition before we'll vote.
> That should include bugzilla reporting script and maybe other git hooks?
> Do we have a checklist of these? Jason?

As far as I can see, the SVN hooks only send email to the *cvs and
gcc-bugzilla lists, that shouldn't be hard to mimic.

I think we also want to decide on policies for creating branches/tags,
deleting refs, or pushing non-fast-forward updates.  In the current
mirror you can delete branches in your own subdirectory, but not other
branches.

Jason

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Martin Liška]

On 8/3/19 12:31 AM, Jason Merrill wrote:
> On Fri, Aug 2, 2019 at 7:35 AM Martin Liška <mliska@suse.cz> wrote:
>>
>> On 8/2/19 1:06 PM, Richard Biener wrote:
>>> On Fri, Aug 2, 2019 at 1:01 PM Martin Liška <mliska@suse.cz> wrote:
>>>>
>>>> On 8/2/19 12:54 PM, Maxim Kuvyrkov wrote:
>>>>>> On Aug 2, 2019, at 1:26 PM, Martin Liška <mliska@suse.cz> wrote:
>>>>>>
>>>>>> On 8/2/19 10:41 AM, Maxim Kuvyrkov wrote:
>>>>>>> In the end, I don't care much to which version of the repo we switch, as long as we switch.
>>>>>>
>>>>>> Hi Maxim.
>>>>>>
>>>>>> I really appreciate that you've been working on that. Same as you I would like to see
>>>>>> any change that will lead to a git repository.
>>>>>>
>>>>>> I have couple of questions about the upcoming Cauldron:
>>>>>>
>>>>>> - Are you planning to attend?
>>>>>
>>>>> Unfortunately, I won't attend this time.
>>>>
>>>> I see.
>>>>
>>>>>
>>>>>> - Would it be possible to prepare a voting during e.g. Steering Committee where
>>>>>>  we'll vote about transition options?
>>>>>> - Would it make sense to do an online questionnaire in advance in order
>>>>>>  to guess what's prevailing opinion?
>>>>>>
>>>>>> If you are interested, I can help you?
>>>>>
>>>>> Let's organize an online survey now.  While most active GCC developers will attend Cauldron, many others will not, so we shouldn't rely on Cauldron to make any final decisions.
>>>>
>>>> Sure, online is the best option as all active community members can vote.
>>>>
>>>>>
>>>>> Martin, would you please organize the survey?
>>>>
>>>> Yes, but I haven't followed the discussion in recent weeks. Is the only question
>>>> whether we want the current GIT mirror or your rebased git repository?
>>>> Is Eric Raymond's transition still in play or not?
>>>
>>> 1) Stay with SVN
>>> 2) Switch to the existing GIT mirror
>>> 3) Wait for ERS to complete his conversion to GIT
>>> 4) Use the existing new conversion to GIT fixing authors and commit messages
>>> 5) I don't care
>>> 6) I don't care as long as we switch to GIT
>>>
>>>> Are there any other sub-question regarding commit message format, git hooks, etc.
>>>> that will deserve a place in the questionnaire?
>>>
>>> No, please do not make it unnecessarily complicated.  Maybe the questionaire
>>> can include a free-form text field for more comments.
>>>
>>> Btw, I do not believe we should do this kind of voting.  Who's eligible to vote?
>>> Is the vote anonymous?  What happens when the majority (what is the majority?)
>>> votes for option N?
>>>
>>> IMHO voting is bike-shedding.
>>>
>>> Those who do the work decide.  _They_ may ask questions _and_ decide whether
>>> to listen to the answer.
>>>
>>> Richard.
>>>
>>>> Thank,
>>>> Martin
>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> --
>>>>> Maxim Kuvyrkov
>>>>> www.linaro.org
>>>>>
>>>>
>>
>> So Richi is suggesting to finish all necessary for transition before we'll vote.
>> That should include bugzilla reporting script and maybe other git hooks?
>> Do we have a checklist of these? Jason?
> 
> As far as I can see, the SVN hooks only send email to the *cvs and
> gcc-bugzilla lists, that shouldn't be hard to mimic.
> 
> I think we also want to decide on policies for creating branches/tags,
> deleting refs, or pushing non-fast-forward updates.  In the current
> mirror you can delete branches in your own subdirectory, but not other
> branches.
> 
> Jason
> 

Hello.

Based on the IRC discussion with Jakub, there's missing key element of the transition.
Jakub requests to have a monotonically increasing revisions (aka rXXXXXXX) to be assigned
for the future git revisions. These will be linked from bugzilla and http://gcc.gnu.org/rNNNNN

I don't like the suggested requirement and I would prefer to use git hashes for both bugzilla
links and general references to revisions. That's what all projects using git do.

As it's still unresolved, I'm not planning to organize any GIT transition survey.

Martin

Monotonically increasing counter (was Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git)

[Jason Merrill]

On Mon, Aug 5, 2019 at 9:20 AM Martin Liška <mliska@suse.cz> wrote:

> Based on the IRC discussion with Jakub, there's missing key element of the transition.
> Jakub requests to have a monotonically increasing revisions (aka rXXXXXXX) to be assigned
> for the future git revisions. These will be linked from bugzilla and http://gcc.gnu.org/rNNNNN
>
> I don't like the suggested requirement and I would prefer to use git hashes for both bugzilla
> links and general references to revisions. That's what all projects using git do.

I agree.  But for those who want a monotonically increasing
identifier, there's already one in git: CommitDate.  In the discussion
of this issue four years ago,

https://gcc.gnu.org/ml/gcc/2015-09/threads.html#00028

I provided a set of git aliases to generate and use reposurgeon-style
action stamps for naming commits.  For Jakub's use-case, the committer
part of the action stamp is probably unnecessary, just the date/time
part should be enough.

Looking at it again, I notice that the different timezones in the
committer date would interfere with sorting, so this update to the
stamp alias uses UTC unconditionally:

stamp = "!f(){ TZ=UTC git show -s
--date='format-local:%Y-%m-%dT%H:%M:%SZ' --format='%cd!%ce'
${1:+\"$@\"}; }; f"

To drop the committer from the stamp, remove "!%ce" from the format argument.

Jakub, it seems to me that this should do the trick for you; binaries
would be named by date/time rather than by revision.  What do you
think?

Jason

Re: Monotonically increasing counter (was Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git)

[Jakub Jelinek]

On Mon, Aug 05, 2019 at 11:20:09AM -0400, Jason Merrill wrote:
> I agree.  But for those who want a monotonically increasing
> identifier, there's already one in git: CommitDate.  In the discussion
> of this issue four years ago,

While commit date is monotonically increasing, it has the problem that at
certain dates there are very few commits, at others many.  When doing
bisection by hand, one does the revision computation (min+max)/2 in head
(it doesn't have to be precise of course, just roughly, and isn't perfect
either, because in svn all of trunk and branches contribute to the revision
numbers), with dates it would be division into further uneven chunks.

Could we tag the branchpoints, say when we branch off gcc 10, we tag the
branchpoint as tags/r11 and then we could use r11-123 as 123th commit on the
trunk since the branchpoint, and let bugzilla and web redirection handle
those rNN-NNNN style identifiers?
git describe --all --match 'r[0-9]*' ... | sed ...
to map hashes etc. to these rNN-NNNN identifiers and something to map them
back to hashes say for git web?

	Jakub

Re: Monotonically increasing counter (was Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git)

[Richard Earnshaw (lists)]

On 05/08/2019 16:34, Jakub Jelinek wrote:
> On Mon, Aug 05, 2019 at 11:20:09AM -0400, Jason Merrill wrote:
>> I agree.  But for those who want a monotonically increasing
>> identifier, there's already one in git: CommitDate.  In the discussion
>> of this issue four years ago,
> 
> While commit date is monotonically increasing, it has the problem that at
> certain dates there are very few commits, at others many.  When doing
> bisection by hand, one does the revision computation (min+max)/2 in head
> (it doesn't have to be precise of course, just roughly, and isn't perfect
> either, because in svn all of trunk and branches contribute to the revision
> numbers), with dates it would be division into further uneven chunks.
> 
> Could we tag the branchpoints, say when we branch off gcc 10, we tag the
> branchpoint as tags/r11 and then we could use r11-123 as 123th commit on the
> trunk since the branchpoint, and let bugzilla and web redirection handle
> those rNN-NNNN style identifiers?
> git describe --all --match 'r[0-9]*' ... | sed ...
> to map hashes etc. to these rNN-NNNN identifiers and something to map them
> back to hashes say for git web?
> 
> 	Jakub
> 

git rev-list --reverse branchtag..branchname

Will list all the revs on that branch from branchtag through to the head 
of the branch.  I guess you could then count the individual revs on that 
list to index them.

R

Re: Monotonically increasing counter (was Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git)

[Jason Merrill]

On 8/5/19 11:34 AM, Jakub Jelinek wrote:
> On Mon, Aug 05, 2019 at 11:20:09AM -0400, Jason Merrill wrote:
>> I agree.  But for those who want a monotonically increasing
>> identifier, there's already one in git: CommitDate.  In the discussion
>> of this issue four years ago,
> 
> While commit date is monotonically increasing, it has the problem that at
> certain dates there are very few commits, at others many.  When doing
> bisection by hand, one does the revision computation (min+max)/2 in head
> (it doesn't have to be precise of course, just roughly, and isn't perfect
> either, because in svn all of trunk and branches contribute to the revision
> numbers), with dates it would be division into further uneven chunks.

That's true, but is it a major problem?  If you have multiple commits on 
one day, you (can) have multiple binaries with the same date and 
different times, and you can adjust your heuristic for choosing the next 
bisection point accordingly.  Over longer periods, the number of commits 
per day averages out.

> Could we tag the branchpoints, say when we branch off gcc 10, we tag the
> branchpoint as tags/r11 and then we could use r11-123 as 123th commit on the
> trunk since the branchpoint, and let bugzilla and web redirection handle
> those rNN-NNNN style identifiers?
> git describe --all --match 'r[0-9]*' ... | sed ...
> to map hashes etc. to these rNN-NNNN identifiers and something to map them
> back to hashes say for git web?

Well, having such tags would allow git describe to produce identifiers 
that you might find more readable.  For instance, if I do

git tag -a -m 'GCC 9 branchpoint' b9 $(git merge-base trunk gcc-9-branch)
git describe trunk

I get

b9-2260-gdb868bacf6a

i.e. commit #2260 since tag b9, with abbreviated hash gdb868bacf6a.

or if I do

git tag -a -m'Beginning of Time' r1 3cf0d8938a953ef13e57239613d42686f152b4fe
git describe --match r1 trunk

r1-170718-gdb868bacf6a

These tags don't need to be shared, this works fine locally.

Note that when you feed such an identifier to other git commands, they 
ignore the first two parts and just use the hash.

This might be a good alternative to dates for you, and people could 
refer to them interchangeably with raw hashes in the web interface.

Jason

Re: Monotonically increasing counter (was Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git)

[Jason Merrill]

On Mon, Aug 5, 2019 at 2:22 PM Jason Merrill <jason@redhat.com> wrote:
> On 8/5/19 11:34 AM, Jakub Jelinek wrote:
> > On Mon, Aug 05, 2019 at 11:20:09AM -0400, Jason Merrill wrote:
> >> I agree.  But for those who want a monotonically increasing
> >> identifier, there's already one in git: CommitDate.  In the discussion
> >> of this issue four years ago,
> >
> > While commit date is monotonically increasing, it has the problem that at
> > certain dates there are very few commits, at others many.  When doing
> > bisection by hand, one does the revision computation (min+max)/2 in head
> > (it doesn't have to be precise of course, just roughly, and isn't perfect
> > either, because in svn all of trunk and branches contribute to the revision
> > numbers), with dates it would be division into further uneven chunks.
>
> That's true, but is it a major problem?  If you have multiple commits on
> one day, you (can) have multiple binaries with the same date and
> different times, and you can adjust your heuristic for choosing the next
> bisection point accordingly.  Over longer periods, the number of commits
> per day averages out.
>
> > Could we tag the branchpoints, say when we branch off gcc 10, we tag the
> > branchpoint as tags/r11 and then we could use r11-123 as 123th commit on the
> > trunk since the branchpoint, and let bugzilla and web redirection handle
> > those rNN-NNNN style identifiers?
> > git describe --all --match 'r[0-9]*' ... | sed ...
> > to map hashes etc. to these rNN-NNNN identifiers and something to map them
> > back to hashes say for git web?
>
> Well, having such tags would allow git describe to produce identifiers
> that you might find more readable.  For instance, if I do
>
> git tag -a -m 'GCC 9 branchpoint' b9 $(git merge-base trunk gcc-9-branch)

Though I guess what you were suggesting is slightly different: this
will put the tag in the history of both trunk and branch, and it would
be better for "r11" to be only in the history of GCC 11.  So probably
best to tag the commit that bumps BASE-VER instead, i.e.

$ git tag -a -m 'GCC 10 stage 1 open' gcc10
70f448fa5347ba24e0916201dd8549bc16783ff0
$ git tag -a -m 'GCC 9 stage 1 open' gcc9
949bc65ce4d0d7dd036ccfb279bffe63d02feee6
$ git tag -a -m 'GCC 8 stage 1 open' gcc8
498621e8159c1f494a9b8a5f2c3e5225c74ed242
...
$ git describe trunk
gcc10-2527-gac18cc031cd
$ git describe gcc-9-branch
gcc9-7633-g28a024c36af

Does this sound good to you?  Anyone have thoughts about naming for the tags?

Since alphabetical sorting won't do well with gcc9 and gcc10, you may
want to use the beginning of time tag for naming your binaries.  Also
because the stage 1 boundary isn't that interesting for bisection.

Jason

> git tag -a -m'Beginning of Time' r1 3cf0d8938a953ef13e57239613d42686f152b4fe
> git describe --match r1 trunk
>
> r1-170718-gdb868bacf6a
>
> These tags don't need to be shared, this works fine locally.
>
> Note that when you feed such an identifier to other git commands, they
> ignore the first two parts and just use the hash.
>
> This might be a good alternative to dates for you, and people could
> refer to them interchangeably with raw hashes in the web interface.

Re: Monotonically increasing counter (was Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git)

[Jason Merrill]

On Wed, Aug 14, 2019 at 2:14 PM Jason Merrill <jason@redhat.com> wrote:
> On Mon, Aug 5, 2019 at 2:22 PM Jason Merrill <jason@redhat.com> wrote:
> > On 8/5/19 11:34 AM, Jakub Jelinek wrote:
> > > On Mon, Aug 05, 2019 at 11:20:09AM -0400, Jason Merrill wrote:
> > >> I agree.  But for those who want a monotonically increasing
> > >> identifier, there's already one in git: CommitDate.  In the discussion
> > >> of this issue four years ago,
> > >
> > > While commit date is monotonically increasing, it has the problem that at
> > > certain dates there are very few commits, at others many.  When doing
> > > bisection by hand, one does the revision computation (min+max)/2 in head
> > > (it doesn't have to be precise of course, just roughly, and isn't perfect
> > > either, because in svn all of trunk and branches contribute to the revision
> > > numbers), with dates it would be division into further uneven chunks.
> >
> > That's true, but is it a major problem?  If you have multiple commits on
> > one day, you (can) have multiple binaries with the same date and
> > different times, and you can adjust your heuristic for choosing the next
> > bisection point accordingly.  Over longer periods, the number of commits
> > per day averages out.
> >
> > > Could we tag the branchpoints, say when we branch off gcc 10, we tag the
> > > branchpoint as tags/r11 and then we could use r11-123 as 123th commit on the
> > > trunk since the branchpoint, and let bugzilla and web redirection handle
> > > those rNN-NNNN style identifiers?
> > > git describe --all --match 'r[0-9]*' ... | sed ...
> > > to map hashes etc. to these rNN-NNNN identifiers and something to map them
> > > back to hashes say for git web?
> >
> > Well, having such tags would allow git describe to produce identifiers
> > that you might find more readable.  For instance, if I do
> >
> > git tag -a -m 'GCC 9 branchpoint' b9 $(git merge-base trunk gcc-9-branch)
>
> Though I guess what you were suggesting is slightly different: this
> will put the tag in the history of both trunk and branch, and it would
> be better for "r11" to be only in the history of GCC 11.  So probably
> best to tag the commit that bumps BASE-VER instead, i.e.
>
> $ git tag -a -m 'GCC 10 stage 1 open' gcc10
> 70f448fa5347ba24e0916201dd8549bc16783ff0
> $ git tag -a -m 'GCC 9 stage 1 open' gcc9
> 949bc65ce4d0d7dd036ccfb279bffe63d02feee6
> $ git tag -a -m 'GCC 8 stage 1 open' gcc8
> 498621e8159c1f494a9b8a5f2c3e5225c74ed242
> ...
> $ git describe trunk
> gcc10-2527-gac18cc031cd
> $ git describe gcc-9-branch
> gcc9-7633-g28a024c36af
>
> Does this sound good to you?  Anyone have thoughts about naming for the tags?
>
> Since alphabetical sorting won't do well with gcc9 and gcc10, you may
> want to use the beginning of time tag for naming your binaries.  Also
> because the stage 1 boundary isn't that interesting for bisection.
>
> > git tag -a -m'Beginning of Time' r1 3cf0d8938a953ef13e57239613d42686f152b4fe
> > git describe --match r1 trunk
> >
> > r1-170718-gdb868bacf6a
> >
> > These tags don't need to be shared, this works fine locally.
> >
> > Note that when you feed such an identifier to other git commands, they
> > ignore the first two parts and just use the hash.
> >
> > This might be a good alternative to dates for you, and people could
> > refer to them interchangeably with raw hashes in the web interface.

I suppose we also need to decide what form we want to use for the
equivalent of gcc.gnu.org/rNNNNN.  I figure it needs to be some prefix
followed by a "commit-ish" (hash, tag, etc.).  Perhaps "g:" as the
prefix, so

gcc.gnu.org/g:HEAD
gcc.gnu.org/g:gcc-9-branch
gcc.gnu.org/g:3cf0d8938a953e

?

Jason

Re: Monotonically increasing counter (was Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git)

[Segher Boessenkool]

On Thu, Sep 19, 2019 at 03:29:27PM -0400, Jason Merrill wrote:
> I suppose we also need to decide what form we want to use for the
> equivalent of gcc.gnu.org/rNNNNN.  I figure it needs to be some prefix
> followed by a "commit-ish" (hash, tag, etc.).  Perhaps "g:" as the
> prefix, so
> 
> gcc.gnu.org/g:HEAD
> gcc.gnu.org/g:gcc-9-branch
> gcc.gnu.org/g:3cf0d8938a953e

Hrm, but we should probably not allow everything here, some things can
be expensive to compute (HEAD~123456 for example), and we don't want to
expose the reflog on the server (if there even is one), etc.  OTOH
allowing pretty much everything here is a quite neat idea.

What do we use for gitweb thing?  That might have a solution for this
already.  Currently we seem to use plain gitweb, maybe cgit or similar
would be nicer?  It looks more modern, anyway :-P


Segher

Re: Monotonically increasing counter (was Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git)

[Nicholas Krause]

On 9/21/19 2:18 PM, Segher Boessenkool wrote:
> On Thu, Sep 19, 2019 at 03:29:27PM -0400, Jason Merrill wrote:
>> I suppose we also need to decide what form we want to use for the
>> equivalent of gcc.gnu.org/rNNNNN.  I figure it needs to be some prefix
>> followed by a "commit-ish" (hash, tag, etc.).  Perhaps "g:" as the
>> prefix, so
>>
>> gcc.gnu.org/g:HEAD
>> gcc.gnu.org/g:gcc-9-branch
>> gcc.gnu.org/g:3cf0d8938a953e
> Hrm, but we should probably not allow everything here, some things can
> be expensive to compute (HEAD~123456 for example), and we don't want to
> expose the reflog on the server (if there even is one), etc.  OTOH
> allowing pretty much everything here is a quite neat idea.
>
> What do we use for gitweb thing?  That might have a solution for this
> already.  Currently we seem to use plain gitweb, maybe cgit or similar
> would be nicer?  It looks more modern, anyway :-P
>
>
> Segher

If I recall correctly using git branches based off tags is the preferred 
way. And to

Seger's point after a server there is none after pulling down in git. 
Everything is

off line unless he means something else. The biggest thing as I pointed 
out at

Cauldron in terms of issues are:

a) How much history do you need in terms of how far back for git bisect 
or rebasing

and

b. Branching after a major release or for other non trunk branches. How 
to allow

other branches or how to set them up using tags e.t.c in git for this.

Mostly the problem with git is getting in right for these two based on 
the project

requirments,

Nick

Re: Monotonically increasing counter (was Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git)

[Jason Merrill]

On Sat, Sep 21, 2019 at 2:18 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Thu, Sep 19, 2019 at 03:29:27PM -0400, Jason Merrill wrote:
> > I suppose we also need to decide what form we want to use for the
> > equivalent of gcc.gnu.org/rNNNNN.  I figure it needs to be some prefix
> > followed by a "commit-ish" (hash, tag, etc.).  Perhaps "g:" as the
> > prefix, so
> >
> > gcc.gnu.org/g:HEAD
> > gcc.gnu.org/g:gcc-9-branch
> > gcc.gnu.org/g:3cf0d8938a953e
>
> Hrm, but we should probably not allow everything here, some things can
> be expensive to compute (HEAD~123456 for example), and we don't want to
> expose the reflog on the server (if there even is one), etc.  OTOH
> allowing pretty much everything here is a quite neat idea.
>
> What do we use for gitweb thing?  That might have a solution for this
> already.  Currently we seem to use plain gitweb, maybe cgit or similar
> would be nicer?  It looks more modern, anyway :-P

The current gitweb allows all of my examples with a bit longer URL, e.g.

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3cf0d8938a953e

it doesn't seem to allow HEAD~1 or HEAD^.  It does allow HEAD@{2}, but
I don't see what the problem with that would be.

I was figuring to just rewrite the /g: pattern into the appropriate
query URL for the git web interface.

I have no opinion about which web interface to use.  Apparently there
are many: https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Web_Interfaces

Jason

Re: Monotonically increasing counter (was Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git)

[Segher Boessenkool]

On Sat, Sep 21, 2019 at 05:32:03PM -0400, Jason Merrill wrote:
> On Sat, Sep 21, 2019 at 2:18 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> >
> > On Thu, Sep 19, 2019 at 03:29:27PM -0400, Jason Merrill wrote:
> > > I suppose we also need to decide what form we want to use for the
> > > equivalent of gcc.gnu.org/rNNNNN.  I figure it needs to be some prefix
> > > followed by a "commit-ish" (hash, tag, etc.).  Perhaps "g:" as the
> > > prefix, so
> > >
> > > gcc.gnu.org/g:HEAD
> > > gcc.gnu.org/g:gcc-9-branch
> > > gcc.gnu.org/g:3cf0d8938a953e
> >
> > Hrm, but we should probably not allow everything here, some things can
> > be expensive to compute (HEAD~123456 for example), and we don't want to
> > expose the reflog on the server (if there even is one), etc.  OTOH
> > allowing pretty much everything here is a quite neat idea.
> >
> > What do we use for gitweb thing?  That might have a solution for this
> > already.  Currently we seem to use plain gitweb, maybe cgit or similar
> > would be nicer?  It looks more modern, anyway :-P
> 
> The current gitweb allows all of my examples with a bit longer URL, e.g.
> 
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3cf0d8938a953e

Yeah, they are all just refs, that should never be a problem.

> it doesn't seem to allow HEAD~1 or HEAD^.  It does allow HEAD@{2}, but
> I don't see what the problem with that would be.

It is an O(n) amount of work for the web server.  But not bigger than our
reflogs are, so that is fine if we run gc often enough (which we should
anyway, to keep a healthy fast repo).

This would be a much bigger problem for ~ because a) that isn't limited
in a similar way, and b) it is more expensive in any case (you have to
follow refs to get to the previous version, not simply go to the next
line in a file).

> I was figuring to just rewrite the /g: pattern into the appropriate
> query URL for the git web interface.

Yeah.  I'm just cautious about the potential for DoS.  But it looks to
be okay.

gitweb disallows some specific characters (and character sequences) here:

	if ($input =~ m!(/\.|\.\.|[\000-\040\177 ~^:?*\[]|/$)!) {
		return undef;
	}

> I have no opinion about which web interface to use.  Apparently there
> are many: https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Web_Interfaces

Yes, and that is independent of the actual move to git; what we have now
will do for now, and OTOH the web thing can be changed already if we want
to do that.

I like that g: syntax btw.


Segher

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Segher Boessenkool]

On Fri, Aug 02, 2019 at 01:06:12PM +0200, Richard Biener wrote:
> 1) Stay with SVN
> 2) Switch to the existing GIT mirror
> 3) Wait for ERS to complete his conversion to GIT
> 4) Use the existing new conversion to GIT fixing authors and commit messages
> 5) I don't care
> 6) I don't care as long as we switch to GIT

7) I don't care as long as we do either 2) or 4).

> IMHO voting is bike-shedding.

Yes, that is the definition of voting, pretty much.

> Those who do the work decide.  _They_ may ask questions _and_ decide whether
> to listen to the answer.

But unfortunately we have been deadlocked for years now.


Segher

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On Aug 2, 2019, at 2:06 PM, Richard Biener <richard.guenther@gmail.com> wrote:
> 
> On Fri, Aug 2, 2019 at 1:01 PM Martin Liška <mliska@suse.cz> wrote:
>> 
>> On 8/2/19 12:54 PM, Maxim Kuvyrkov wrote:
>>>> On Aug 2, 2019, at 1:26 PM, Martin Liška <mliska@suse.cz> wrote:
>>>> 
>>>> On 8/2/19 10:41 AM, Maxim Kuvyrkov wrote:
>>>>> In the end, I don't care much to which version of the repo we switch, as long as we switch.
>>>> 
>>>> Hi Maxim.
>>>> 
>>>> I really appreciate that you've been working on that. Same as you I would like to see
>>>> any change that will lead to a git repository.
>>>> 
>>>> I have couple of questions about the upcoming Cauldron:
>>>> 
>>>> - Are you planning to attend?
>>> 
>>> Unfortunately, I won't attend this time.
>> 
>> I see.
>> 
>>> 
>>>> - Would it be possible to prepare a voting during e.g. Steering Committee where
>>>> we'll vote about transition options?
>>>> - Would it make sense to do an online questionnaire in advance in order
>>>> to guess what's prevailing opinion?
>>>> 
>>>> If you are interested, I can help you?
>>> 
>>> Let's organize an online survey now.  While most active GCC developers will attend Cauldron, many others will not, so we shouldn't rely on Cauldron to make any final decisions.
>> 
>> Sure, online is the best option as all active community members can vote.
>> 
>>> 
>>> Martin, would you please organize the survey?
>> 
>> Yes, but I haven't followed the discussion in recent weeks. Is the only question
>> whether we want the current GIT mirror or your rebased git repository?
>> Is Eric Raymond's transition still in play or not?
> 
> 1) Stay with SVN
> 2) Switch to the existing GIT mirror
> 3) Wait for ERS to complete his conversion to GIT
> 4) Use the existing new conversion to GIT fixing authors and commit messages
> 5) I don't care
> 6) I don't care as long as we switch to GIT
> 
>> Are there any other sub-question regarding commit message format, git hooks, etc.
>> that will deserve a place in the questionnaire?
> 
> No, please do not make it unnecessarily complicated.  Maybe the questionaire
> can include a free-form text field for more comments.
> 
> Btw, I do not believe we should do this kind of voting.  Who's eligible to vote?
> Is the vote anonymous?  What happens when the majority (what is the majority?)
> votes for option N?
> 
> IMHO voting is bike-shedding.
> 
> Those who do the work decide.  _They_ may ask questions _and_ decide whether
> to listen to the answer.

I think we should do a /survey/, not organize a vote.  From reading this thread an independent observer will get an impression that GCC developers are split into 3 roughly equal parts:
1. those who prefer switch to existing mirror,
2. those who prefer to wait for reposurgeon conversion,
3. those who prefer to switch to svn-git conversion with authors fixed.

The survey might show that we have a clear majority for one of the options, and that we can conclude the discussion.  If survey shows that we don't have a clear winner, then let's continue the discussion.

IMO, anyone who considers himself or herself a GCC developer should participate and survey should not be anonymous to avoid abuse.

--
Maxim Kuvyrkov
www.linaro.org

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Mike Stump]

On Aug 2, 2019, at 4:06 AM, Richard Biener <richard.guenther@gmail.com> wrote:
> 
> IMHO voting is bike-shedding.
> 
> Those who do the work decide.  _They_ may ask questions _and_ decide whether
> to listen to the answer.

I'd tend to agree.  I also think the recent conversion work is a fine solution, and that my preference for that might influence my agreement here.

I don't think we should maintain a requirement that we have monotonic numbers going forward.  That's just not the git way.  I've been known to do git log, and then manually pick start and end, and then bisect based upon not date, but out of a large hash list.  The concerns that some dates have a ton and other dates have few, doesn't come in to play, as each hash is 1 unit of work, so a list of 10235 hashs, can be trivially split into 2, 3, 4 or 1042, if you have the machines for it.

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On Aug 2, 2019, at 11:41 AM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
> 
>> On Aug 1, 2019, at 11:43 PM, Jason Merrill <jason@redhat.com> wrote:
>> 
...
>>> Unfortunately, current mirror does not and could not account for rewrites of SVN commit log messages.  For trunk the histories of diverge in 2008 due to commit message change of r138154.  This is not a single occurrence; I've compared histories only of trunk and gcc-6-branch, and both had commit message change (for gcc-6-branch see r259978).
>>> 
>>> It's up to the community is to weigh pros and cons of re-using existing GCC mirror as conversion base vs regenerating history from scratch:
>>> 
>>> Pros of using GCC mirror:
>>> + No need to rebase public git-only branches
>>> + No need to rebase private branches
>>> + No need to rebase current clones, checkouts, work-in-progress trees
>>> 
>>> Cons of using GCC mirror:
>>> - Poor author / committer IDs (this breaks patch statistics software)
>>> - Several commit messages will not be the current "fixed" version
>>> 
>>> Thoughts?
>> 
>> I'm still inclined to stick with the mirror.  I would expect patch
>> statistics software to be able to be taught about multiple addresses
>> for the same person.
> 
> Patch tracking software breaks on emails like <fxcoudert@138bc75d-0d04-0410-961f-82ee72b054a4> , where 38bc75d-0d04-0410-961f-82ee72b054a4 is not a reasonable domain name.
> 
> For completeness, I'll generate and upload a repo based on current mirror with all branches and tags converted.

Yeah, this didn't worked as well as I hoped.  Current gcc git mirror has wrong history for branches that followed scenario:
1. create $branch from $base at revision N
2. commit WORK on $branch
3. delete $branch
4. create $branch from $base at revision N+M
5. rebase WORK on current $branch

Current mirror connects histories of two versions of $branch, and we get wrong history.  In step (4) instead of plain history of $base we get a commit merging histories of $branch just before deletion and $base at revision N+M.

There are many branches like this, e.g., branches/gccgo.

--
Maxim Kuvyrkov
www.linaro.org

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On Aug 5, 2019, at 11:24 AM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
> 
> 
>> On Aug 2, 2019, at 11:41 AM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
>> 
>>> On Aug 1, 2019, at 11:43 PM, Jason Merrill <jason@redhat.com> wrote:
>>> 
> ...
>>>> Unfortunately, current mirror does not and could not account for rewrites of SVN commit log messages.  For trunk the histories of diverge in 2008 due to commit message change of r138154.  This is not a single occurrence; I've compared histories only of trunk and gcc-6-branch, and both had commit message change (for gcc-6-branch see r259978).
>>>> 
>>>> It's up to the community is to weigh pros and cons of re-using existing GCC mirror as conversion base vs regenerating history from scratch:
>>>> 
>>>> Pros of using GCC mirror:
>>>> + No need to rebase public git-only branches
>>>> + No need to rebase private branches
>>>> + No need to rebase current clones, checkouts, work-in-progress trees
>>>> 
>>>> Cons of using GCC mirror:
>>>> - Poor author / committer IDs (this breaks patch statistics software)
>>>> - Several commit messages will not be the current "fixed" version
>>>> 
>>>> Thoughts?
>>> 
>>> I'm still inclined to stick with the mirror.  I would expect patch
>>> statistics software to be able to be taught about multiple addresses
>>> for the same person.
>> 
>> Patch tracking software breaks on emails like <fxcoudert@138bc75d-0d04-0410-961f-82ee72b054a4> , where 38bc75d-0d04-0410-961f-82ee72b054a4 is not a reasonable domain name.
>> 
>> For completeness, I'll generate and upload a repo based on current mirror with all branches and tags converted.
> 
> Yeah, this didn't worked as well as I hoped.  Current gcc git mirror has wrong history for branches that followed scenario:
> 1. create $branch from $base at revision N
> 2. commit WORK on $branch
> 3. delete $branch
> 4. create $branch from $base at revision N+M
> 5. rebase WORK on current $branch
> 
> Current mirror connects histories of two versions of $branch, and we get wrong history.  In step (4) instead of plain history of $base we get a commit merging histories of $branch just before deletion and $base at revision N+M.
> 
> There are many branches like this, e.g., branches/gccgo.

I've setup uploads and updates of fully converted GCC history (all branches and all tags) in 3 flavors.  These will be updated roughly hourly.

1. https://git-us.linaro.org/people/maxim-kuvyrkov/gcc-pretty.git/
This is a fresh conversion from scratch with "pretty" authors.

2. https://git.linaro.org/people/maxim-kuvyrkov/gcc-mirror.git/
This is a close match to current GCC mirror.  Trunk and gcc-*-branch branches are imported from the mirror, and the rest is reconstructed starting from the imported branches.

3. https://git-us.linaro.org/people/maxim-kuvyrkov/gcc-raw.git/
This is a fresh conversion from scratch with no author rewrites.

--
Maxim Kuvyrkov
www.linaro.org

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On Aug 6, 2019, at 12:32 PM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
> 
...
> I've setup uploads and updates of fully converted GCC history (all branches and all tags) in 3 flavors.  These will be updated roughly hourly.
> 
> 1. https://git-us.linaro.org/people/maxim-kuvyrkov/gcc-pretty.git/
> This is a fresh conversion from scratch with "pretty" authors.
> 
> 2. https://git.linaro.org/people/maxim-kuvyrkov/gcc-mirror.git/
> This is a close match to current GCC mirror.  Trunk and gcc-*-branch branches are imported from the mirror, and the rest is reconstructed starting from the imported branches.
> 
> 3. https://git-us.linaro.org/people/maxim-kuvyrkov/gcc-raw.git/
> This is a fresh conversion from scratch with no author rewrites.
> 

The conversion is now fully complete.  The above 3 repositories all have complete and accurate [1] history of all branches and tags.  SVN's /branches/* are converted to Git's refs/heads/*, and SVN's /tags/* are converted to Git's annotated tags refs/tags/*.  SVN's /trunk is Git's refs/heads/master.

I propose that we switch to gcc-pretty.git repository, because it has accurate Committer and Author fields.  Developer names and email addresses are extracted from source history, and accurately track people changing companies, email addresses, and names.  IMO, it is more important for people to get credit for open-source contributions on github, ohloh, etc., than the inconvenience of rebasing local git branches.  It's also an important marketing tool for open-source companies to show stats of their corporate email addresses appearing in git commit logs.

I also suggest that we don't wait for Cauldron to make plan on when and how to switch.  I believe the big decisions should be made on the mailing list, and at Cauldron we can discuss finer points.  [Also, unfortunately, I won't attend this year.]


[1] Gcc-mirror.git has artifacts in several commit messages due to edits of SVN commit messages after the fact.

Regards,

--
Maxim Kuvyrkov
www.linaro.org

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Joseph Myers]

On Fri, 23 Aug 2019, Maxim Kuvyrkov wrote:

> I propose that we switch to gcc-pretty.git repository, because it has 
> accurate Committer and Author fields.  Developer names and email 
> addresses are extracted from source history, and accurately track people 
> changing companies, email addresses, and names.  IMO, it is more 
> important for people to get credit for open-source contributions on 
> github, ohloh, etc., than the inconvenience of rebasing local git 
> branches.  It's also an important marketing tool for open-source 
> companies to show stats of their corporate email addresses appearing in 
> git commit logs.

I concur that accurately crediting contributors is important and means we 
should not start from the existing mirror (though we should keep its 
branches available, so references to them and to their commit hashes 
continue to work - either keeping the existing repository available under 
a different name, or renaming the branches to put them in the new 
repository - which should not enlarge the repository much because blob and 
tree objects will generally be shared between the two versions of the 
history).

I note that the Go conversion of reposurgeon is now just five test 
failures away from passing the whole reposurgeon testsuite (at which point 
it should be ready for an attempt on the GCC conversion).  Given the good 
progress being made there at present, I thus suggest we plan to compare 
this conversion with one from reposurgeon (paying special attention to the 
messiest parts of the repository, such as artifacts from cvs2svn 
attempting to locate branchpoints), unless those last five goreposurgeon 
test failures prove unexpectedly time-consuming to get resolved.

There are of course plenty of things to do relating to a git conversion 
that do not depend on the particular choice of a converted repository - 
such as writing git hooks and git versions of the maintainer-scripts 
scripts that currently work with SVN, or working out a specific choice of 
how to arrange annotated tags to allow "git describe" to give the sort of 
monotonic version number some contributors want.

A reasonable starting point for hooks would be that they closely 
approximate what the current SVN hooks do for commit mails to gcc-cvs and 
for Bugzilla updates, as what the current hooks do is clearly OK at 
present and we shouldn't need to entangle substantive changes to what the 
hooks do with the actual conversion to git; we can always discuss changes 
later.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On Aug 24, 2019, at 12:30 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> On Fri, 23 Aug 2019, Maxim Kuvyrkov wrote:
> 
>> I propose that we switch to gcc-pretty.git repository, because it has 
>> accurate Committer and Author fields.  Developer names and email 
>> addresses are extracted from source history, and accurately track people 
>> changing companies, email addresses, and names.  IMO, it is more 
>> important for people to get credit for open-source contributions on 
>> github, ohloh, etc., than the inconvenience of rebasing local git 
>> branches.  It's also an important marketing tool for open-source 
>> companies to show stats of their corporate email addresses appearing in 
>> git commit logs.
> 
> I concur that accurately crediting contributors is important and means we 
> should not start from the existing mirror (though we should keep its 
> branches available, so references to them and to their commit hashes 
> continue to work - either keeping the existing repository available under 
> a different name, or renaming the branches to put them in the new 
> repository - which should not enlarge the repository much because blob and 
> tree objects will generally be shared between the two versions of the 
> history).
> 
> I note that the Go conversion of reposurgeon is now just five test 
> failures away from passing the whole reposurgeon testsuite (at which point 
> it should be ready for an attempt on the GCC conversion).  Given the good 
> progress being made there at present, I thus suggest we plan to compare 
> this conversion with one from reposurgeon (paying special attention to the 
> messiest parts of the repository, such as artifacts from cvs2svn 
> attempting to locate branchpoints), unless those last five goreposurgeon 
> test failures prove unexpectedly time-consuming to get resolved.

Could you upload GCC repo converted with reposurgeon somewhere public?  And also list expected artifacts in its current version?

From my side, the machine on which the conversion ran ran out of disk space about 3 weeks ago.  I'll clean it up and restart the conversion updates.

I'll also improve author entries a bit, so gcc-pretty.git's history will change ever so slightly.

> 
> There are of course plenty of things to do relating to a git conversion 
> that do not depend on the particular choice of a converted repository - 
> such as writing git hooks and git versions of the maintainer-scripts 
> scripts that currently work with SVN, or working out a specific choice of 
> how to arrange annotated tags to allow "git describe" to give the sort of 
> monotonic version number some contributors want.
> 
> A reasonable starting point for hooks would be that they closely 
> approximate what the current SVN hooks do for commit mails to gcc-cvs and 
> for Bugzilla updates, as what the current hooks do is clearly OK at 
> present and we shouldn't need to entangle substantive changes to what the 
> hooks do with the actual conversion to git; we can always discuss changes 
> later.

Would the community please assign a volunteer for this at Cauldron? :-P

Thank you,

--
Maxim Kuvyrkov
www.linaro.org

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On Jul 22, 2019, at 12:05 PM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
> 
...
>>>> As far as GCC conversion goes, below is what I plan to do and what not to do.  This is based on comments from everyone in this thread:
>>>> 
>>>> 1. Construct GCC's git repo from SVN using same settings as current git mirror.
>>>> 2. Compare the resulting git repo with current GCC mirror -- they should match on the commit hash level for trunk, branches/gcc-*-branch, and other "normal" branches.
>>>> 3. Investigate any differences between converted GCC repo and current GCC mirror. These can be due to bugs in git-svn or other misconfigurations.
>>>> 4. Import git-only branches from current GCC mirror.
>>>> 5. Publish this "raw" repo for community to sanity-check its contents.
>>> 
>>> Why not start from the current mirror?  Perhaps a mirror of the mirror?
>> 
>> To check that git-svn is self-consistent and generates same commits now as it was several years ago when you setup the current mirror.  
> 
> Unfortunately, current mirror does not and could not account for rewrites of SVN commit log messages.  For trunk the histories of diverge in 2008 due to commit message change of r138154.  This is not a single occurrence; I've compared histories only of trunk and gcc-6-branch, and both had commit message change (for gcc-6-branch see r259978).
> 
> It's up to the community is to weigh pros and cons of re-using existing GCC mirror as conversion base vs regenerating history from scratch:
> 
> Pros of using GCC mirror:
> + No need to rebase public git-only branches
> + No need to rebase private branches
> + No need to rebase current clones, checkouts, work-in-progress trees
> 
> Cons of using GCC mirror:
> - Poor author / committer IDs (this breaks patch statistics software)
> - Several commit messages will not be the current "fixed" version
> 
> Thoughts?

Ping?

Meanwhile, status update:

1. GitHub blocked https://github.com/maxim-kuvyrkov/gcc/ due to excessive resource usage.  I've asked them to unblock and explained why pushes are as big as they are.

2. I'm uploading to https://git.linaro.org/people/maxim.kuvyrkov/gcc.git/ for now.

3. Conversion is now feature-complete.  The scripts re-write author and committer fields, as well as create proper git tags.

4. "Raw" version of repository is available under refs/raw/*.

5. refs/raw/* are not expected to change.

6. refs/heads/* and refs/tags/* might change due to author/committer name fixes and improvements.

Please scrutinize the repo and let me know of any artifacts.

--
Maxim Kuvyrkov
www.linaro.org

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Maxim Kuvyrkov]

> On Aug 2, 2019, at 11:35 AM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
> 
>> On Jul 22, 2019, at 12:05 PM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
>> 
> ...
>>>>> As far as GCC conversion goes, below is what I plan to do and what not to do.  This is based on comments from everyone in this thread:
>>>>> 
>>>>> 1. Construct GCC's git repo from SVN using same settings as current git mirror.
>>>>> 2. Compare the resulting git repo with current GCC mirror -- they should match on the commit hash level for trunk, branches/gcc-*-branch, and other "normal" branches.
>>>>> 3. Investigate any differences between converted GCC repo and current GCC mirror. These can be due to bugs in git-svn or other misconfigurations.
>>>>> 4. Import git-only branches from current GCC mirror.
>>>>> 5. Publish this "raw" repo for community to sanity-check its contents.
>>>> 
>>>> Why not start from the current mirror?  Perhaps a mirror of the mirror?
>>> 
>>> To check that git-svn is self-consistent and generates same commits now as it was several years ago when you setup the current mirror.  
>> 
>> Unfortunately, current mirror does not and could not account for rewrites of SVN commit log messages.  For trunk the histories of diverge in 2008 due to commit message change of r138154.  This is not a single occurrence; I've compared histories only of trunk and gcc-6-branch, and both had commit message change (for gcc-6-branch see r259978).
>> 
>> It's up to the community is to weigh pros and cons of re-using existing GCC mirror as conversion base vs regenerating history from scratch:
>> 
>> Pros of using GCC mirror:
>> + No need to rebase public git-only branches
>> + No need to rebase private branches
>> + No need to rebase current clones, checkouts, work-in-progress trees
>> 
>> Cons of using GCC mirror:
>> - Poor author / committer IDs (this breaks patch statistics software)
>> - Several commit messages will not be the current "fixed" version
>> 
>> Thoughts?
> 
> Ping?
> 
> Meanwhile, status update:
> 
> 1. GitHub blocked https://github.com/maxim-kuvyrkov/gcc/ due to excessive resource usage. I've asked them to unblock and explained why pushes are as big as they are.
> 
> 2. I'm uploading to https://git.linaro.org/people/maxim.kuvyrkov/gcc.git/ for now.

The correct link is https://git.linaro.org/people/maxim-kuvyrkov/gcc.git/ .  Thanks to Segher for pointing this out.

> 
> 3. Conversion is now feature-complete.  The scripts re-write author and committer fields, as well as create proper git tags.
> 
> 4. "Raw" version of repository is available under refs/raw/*.
> 
> 5. refs/raw/* are not expected to change.
> 
> 6. refs/heads/* and refs/tags/* might change due to author/committer name fixes and improvements.
> 
> Please scrutinize the repo and let me know of any artifacts.


--
Maxim Kuvyrkov
www.linaro.org

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Segher Boessenkool]

On Fri, Aug 02, 2019 at 05:14:20PM +0300, Maxim Kuvyrkov wrote:
> > On Aug 2, 2019, at 11:35 AM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
> >> On Jul 22, 2019, at 12:05 PM, Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> wrote:
> > 3. Conversion is now feature-complete.  The scripts re-write author and committer fields, as well as create proper git tags.
> > 
> > 4. "Raw" version of repository is available under refs/raw/*.
> > 
> > 5. refs/raw/* are not expected to change.
> > 
> > 6. refs/heads/* and refs/tags/* might change due to author/committer name fixes and improvements.
> > 
> > Please scrutinize the repo and let me know of any artifacts.

When cloning it says
  warning: remote HEAD refers to nonexistent ref, unable to checkout.

$ git checkout origin/trunk -b master
seems to fix the local checkout, but of course

$ git remote show origin
still says
  HEAD branch: (unknown)

Other than that, it looks fine.  (I checked all my own entries, and all
got a reasonable email address).


Segher