* [PATCH v5 05/15] Add new simplified git-remote-testgit
From: Felipe Contreras @ 2012-11-11 13:59 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Johannes Schindelin, Max Horn, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips, Felipe Contreras
In-Reply-To: <1352642392-28387-1-git-send-email-felipe.contreras@gmail.com>
It's way simpler. It exerceises the same features of remote helpers.
It's easy to read and understand. It doesn't depend on python.
It does _not_ exercise the python remote helper framework; there's
another tool and another test for that.
For now let's just copy the old remote-helpers test script, although
some of those tests don't make sense for this testgit (they still pass).
In addition, this script would be able to test other features not
currently being tested.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/git-remote-testgit.txt | 2 +-
git-remote-testgit | 62 ++++++++++++++++
t/t5801-remote-helpers.sh | 139 +++++++++++++++++++++++++++++++++++
3 files changed, 202 insertions(+), 1 deletion(-)
create mode 100755 git-remote-testgit
create mode 100755 t/t5801-remote-helpers.sh
diff --git a/Documentation/git-remote-testgit.txt b/Documentation/git-remote-testgit.txt
index 2a67d45..612a625 100644
--- a/Documentation/git-remote-testgit.txt
+++ b/Documentation/git-remote-testgit.txt
@@ -19,7 +19,7 @@ testcase for the remote-helper functionality, and as an example to
show remote-helper authors one possible implementation.
The best way to learn more is to read the comments and source code in
-'git-remote-testgit.py'.
+'git-remote-testgit'.
SEE ALSO
--------
diff --git a/git-remote-testgit b/git-remote-testgit
new file mode 100755
index 0000000..83ccb86
--- /dev/null
+++ b/git-remote-testgit
@@ -0,0 +1,62 @@
+#!/bin/bash
+# Copyright (c) 2012 Felipe Contreras
+
+alias=$1
+url=$2
+
+# huh?
+url="${url#file://}"
+
+dir="$GIT_DIR/testgit/$alias"
+prefix="refs/testgit/$alias"
+refspec="refs/heads/*:${prefix}/heads/*"
+
+gitmarks="$dir/git.marks"
+testgitmarks="$dir/testgit.marks"
+
+export GIT_DIR="$url/.git"
+
+mkdir -p "$dir"
+
+test -e "$gitmarks" || > "$gitmarks"
+test -e "$testgitmarks" || > "$testgitmarks"
+
+while read line; do
+ case $line in
+ capabilities)
+ echo 'import'
+ echo 'export'
+ echo "refspec $refspec"
+ echo "*import-marks $gitmarks"
+ echo "*export-marks $gitmarks"
+ echo
+ ;;
+ list)
+ git for-each-ref --format='? %(refname)' 'refs/heads/'
+ head=$(git symbolic-ref HEAD)
+ echo "@$head HEAD"
+ echo
+ ;;
+ import*)
+ # read all import lines
+ while true; do
+ ref="${line#* }"
+ refs="$refs $ref"
+ read line
+ test "${line%% *}" != "import" && break
+ done
+
+ echo "feature import-marks=$gitmarks"
+ echo "feature export-marks=$gitmarks"
+ git fast-export --use-done-feature --{import,export}-marks="$testgitmarks" $refs | \
+ sed -e "s#refs/heads/#${prefix}/heads/#g"
+ ;;
+ export)
+ git fast-import --{import,export}-marks="$testgitmarks" --quiet
+ echo
+ ;;
+ '')
+ exit
+ ;;
+ esac
+done
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
new file mode 100755
index 0000000..f52ab14
--- /dev/null
+++ b/t/t5801-remote-helpers.sh
@@ -0,0 +1,139 @@
+#!/bin/sh
+#
+# Copyright (c) 2010 Sverre Rabbelier
+#
+
+test_description='Test remote-helper import and export commands'
+
+. ./test-lib.sh
+
+if ! type "${BASH-bash}" >/dev/null 2>&1; then
+ skip_all='skipping remote-testgit tests, bash not available'
+ test_done
+fi
+
+compare_refs() {
+ git --git-dir="$1/.git" rev-parse --verify $2 >expect &&
+ git --git-dir="$3/.git" rev-parse --verify $4 >actual &&
+ test_cmp expect actual
+}
+
+test_expect_success 'setup repository' '
+ git init --bare server/.git &&
+ git clone server public &&
+ (cd public &&
+ echo content >file &&
+ git add file &&
+ git commit -m one &&
+ git push origin master)
+'
+
+test_expect_success 'cloning from local repo' '
+ git clone "testgit::${PWD}/server" localclone &&
+ test_cmp public/file localclone/file
+'
+
+test_expect_success 'cloning from remote repo' '
+ git clone "testgit::file://${PWD}/server" clone &&
+ test_cmp public/file clone/file
+'
+
+test_expect_success 'create new commit on remote' '
+ (cd public &&
+ echo content >>file &&
+ git commit -a -m two &&
+ git push)
+'
+
+test_expect_success 'pulling from local repo' '
+ (cd localclone && git pull) &&
+ test_cmp public/file localclone/file
+'
+
+test_expect_success 'pulling from remote remote' '
+ (cd clone && git pull) &&
+ test_cmp public/file clone/file
+'
+
+test_expect_success 'pushing to local repo' '
+ (cd localclone &&
+ echo content >>file &&
+ git commit -a -m three &&
+ git push) &&
+ compare_refs localclone HEAD server HEAD
+'
+
+# Generally, skip this test. It demonstrates a now-fixed race in
+# git-remote-testgit, but is too slow to leave in for general use.
+: test_expect_success 'racily pushing to local repo' '
+ test_when_finished "rm -rf server2 localclone2" &&
+ cp -R server server2 &&
+ git clone "testgit::${PWD}/server2" localclone2 &&
+ (cd localclone2 &&
+ echo content >>file &&
+ git commit -a -m three &&
+ GIT_REMOTE_TESTGIT_SLEEPY=2 git push) &&
+ compare_refs localclone2 HEAD server2 HEAD
+'
+
+test_expect_success 'synch with changes from localclone' '
+ (cd clone &&
+ git pull)
+'
+
+test_expect_success 'pushing remote local repo' '
+ (cd clone &&
+ echo content >>file &&
+ git commit -a -m four &&
+ git push) &&
+ compare_refs clone HEAD server HEAD
+'
+
+test_expect_success 'fetch new branch' '
+ (cd public &&
+ git checkout -b new &&
+ echo content >>file &&
+ git commit -a -m five &&
+ git push origin new
+ ) &&
+ (cd localclone &&
+ git fetch origin new
+ ) &&
+ compare_refs public HEAD localclone FETCH_HEAD
+'
+
+test_expect_success 'fetch multiple branches' '
+ (cd localclone &&
+ git fetch
+ ) &&
+ compare_refs server master localclone refs/remotes/origin/master &&
+ compare_refs server new localclone refs/remotes/origin/new
+'
+
+test_expect_success 'push when remote has extra refs' '
+ (cd clone &&
+ echo content >>file &&
+ git commit -a -m six &&
+ git push
+ ) &&
+ compare_refs clone master server master
+'
+
+test_expect_success 'push new branch by name' '
+ (cd clone &&
+ git checkout -b new-name &&
+ echo content >>file &&
+ git commit -a -m seven &&
+ git push origin new-name
+ ) &&
+ compare_refs clone HEAD server refs/heads/new-name
+'
+
+test_expect_failure 'push new branch with old:new refspec' '
+ (cd clone &&
+ git push origin new-name:new-refspec
+ ) &&
+ compare_refs clone HEAD server refs/heads/new-refspec
+'
+
+test_done
--
1.8.0
^ permalink raw reply related
* [PATCH v5 04/15] Rename git-remote-testgit to git-remote-testpy
From: Felipe Contreras @ 2012-11-11 13:59 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Johannes Schindelin, Max Horn, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips, Felipe Contreras
In-Reply-To: <1352642392-28387-1-git-send-email-felipe.contreras@gmail.com>
This script is not really exercising the remote-helper functionality,
but more the python framework for remote helpers that live in
git_remote_helpers.
It's also not a good example of how to write remote-helpers, unless you
are planning to use python, and even then you might not want to use this
framework.
So let's use a more appropriate name: git-remote-testpy.
A patch that replaces git-remote-testgit with a simpler version is on
the way.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
.gitignore | 2 +-
Makefile | 2 +-
git-remote-testgit.py | 272 ----------------------------------------------
git-remote-testpy.py | 272 ++++++++++++++++++++++++++++++++++++++++++++++
t/t5800-remote-helpers.sh | 148 -------------------------
t/t5800-remote-testpy.sh | 148 +++++++++++++++++++++++++
6 files changed, 422 insertions(+), 422 deletions(-)
delete mode 100644 git-remote-testgit.py
create mode 100644 git-remote-testpy.py
delete mode 100755 t/t5800-remote-helpers.sh
create mode 100755 t/t5800-remote-testpy.sh
diff --git a/.gitignore b/.gitignore
index a188a82..48d1bbb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -124,7 +124,7 @@
/git-remote-ftps
/git-remote-fd
/git-remote-ext
-/git-remote-testgit
+/git-remote-testpy
/git-repack
/git-replace
/git-repo-config
diff --git a/Makefile b/Makefile
index f69979e..e18ee48 100644
--- a/Makefile
+++ b/Makefile
@@ -470,7 +470,7 @@ SCRIPT_PERL += git-relink.perl
SCRIPT_PERL += git-send-email.perl
SCRIPT_PERL += git-svn.perl
-SCRIPT_PYTHON += git-remote-testgit.py
+SCRIPT_PYTHON += git-remote-testpy.py
SCRIPT_PYTHON += git-p4.py
SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
diff --git a/git-remote-testgit.py b/git-remote-testgit.py
deleted file mode 100644
index ade797b..0000000
--- a/git-remote-testgit.py
+++ /dev/null
@@ -1,272 +0,0 @@
-#!/usr/bin/env python
-
-# This command is a simple remote-helper, that is used both as a
-# testcase for the remote-helper functionality, and as an example to
-# show remote-helper authors one possible implementation.
-#
-# This is a Git <-> Git importer/exporter, that simply uses git
-# fast-import and git fast-export to consume and produce fast-import
-# streams.
-#
-# To understand better the way things work, one can activate debug
-# traces by setting (to any value) the environment variables
-# GIT_TRANSPORT_HELPER_DEBUG and GIT_DEBUG_TESTGIT, to see messages
-# from the transport-helper side, or from this example remote-helper.
-
-# hashlib is only available in python >= 2.5
-try:
- import hashlib
- _digest = hashlib.sha1
-except ImportError:
- import sha
- _digest = sha.new
-import sys
-import os
-import time
-sys.path.insert(0, os.getenv("GITPYTHONLIB","."))
-
-from git_remote_helpers.util import die, debug, warn
-from git_remote_helpers.git.repo import GitRepo
-from git_remote_helpers.git.exporter import GitExporter
-from git_remote_helpers.git.importer import GitImporter
-from git_remote_helpers.git.non_local import NonLocalGit
-
-def get_repo(alias, url):
- """Returns a git repository object initialized for usage.
- """
-
- repo = GitRepo(url)
- repo.get_revs()
- repo.get_head()
-
- hasher = _digest()
- hasher.update(repo.path)
- repo.hash = hasher.hexdigest()
-
- repo.get_base_path = lambda base: os.path.join(
- base, 'info', 'fast-import', repo.hash)
-
- prefix = 'refs/testgit/%s/' % alias
- debug("prefix: '%s'", prefix)
-
- repo.gitdir = os.environ["GIT_DIR"]
- repo.alias = alias
- repo.prefix = prefix
-
- repo.exporter = GitExporter(repo)
- repo.importer = GitImporter(repo)
- repo.non_local = NonLocalGit(repo)
-
- return repo
-
-
-def local_repo(repo, path):
- """Returns a git repository object initalized for usage.
- """
-
- local = GitRepo(path)
-
- local.non_local = None
- local.gitdir = repo.gitdir
- local.alias = repo.alias
- local.prefix = repo.prefix
- local.hash = repo.hash
- local.get_base_path = repo.get_base_path
- local.exporter = GitExporter(local)
- local.importer = GitImporter(local)
-
- return local
-
-
-def do_capabilities(repo, args):
- """Prints the supported capabilities.
- """
-
- print "import"
- print "export"
- print "refspec refs/heads/*:%s*" % repo.prefix
-
- dirname = repo.get_base_path(repo.gitdir)
-
- if not os.path.exists(dirname):
- os.makedirs(dirname)
-
- path = os.path.join(dirname, 'git.marks')
-
- print "*export-marks %s" % path
- if os.path.exists(path):
- print "*import-marks %s" % path
-
- print # end capabilities
-
-
-def do_list(repo, args):
- """Lists all known references.
-
- Bug: This will always set the remote head to master for non-local
- repositories, since we have no way of determining what the remote
- head is at clone time.
- """
-
- for ref in repo.revs:
- debug("? refs/heads/%s", ref)
- print "? refs/heads/%s" % ref
-
- if repo.head:
- debug("@refs/heads/%s HEAD" % repo.head)
- print "@refs/heads/%s HEAD" % repo.head
- else:
- debug("@refs/heads/master HEAD")
- print "@refs/heads/master HEAD"
-
- print # end list
-
-
-def update_local_repo(repo):
- """Updates (or clones) a local repo.
- """
-
- if repo.local:
- return repo
-
- path = repo.non_local.clone(repo.gitdir)
- repo.non_local.update(repo.gitdir)
- repo = local_repo(repo, path)
- return repo
-
-
-def do_import(repo, args):
- """Exports a fast-import stream from testgit for git to import.
- """
-
- if len(args) != 1:
- die("Import needs exactly one ref")
-
- if not repo.gitdir:
- die("Need gitdir to import")
-
- ref = args[0]
- refs = [ref]
-
- while True:
- line = sys.stdin.readline()
- if line == '\n':
- break
- if not line.startswith('import '):
- die("Expected import line.")
-
- # strip of leading 'import '
- ref = line[7:].strip()
- refs.append(ref)
-
- repo = update_local_repo(repo)
- repo.exporter.export_repo(repo.gitdir, refs)
-
- print "done"
-
-
-def do_export(repo, args):
- """Imports a fast-import stream from git to testgit.
- """
-
- if not repo.gitdir:
- die("Need gitdir to export")
-
- update_local_repo(repo)
- changed = repo.importer.do_import(repo.gitdir)
-
- if not repo.local:
- repo.non_local.push(repo.gitdir)
-
- for ref in changed:
- print "ok %s" % ref
- print
-
-
-COMMANDS = {
- 'capabilities': do_capabilities,
- 'list': do_list,
- 'import': do_import,
- 'export': do_export,
-}
-
-
-def sanitize(value):
- """Cleans up the url.
- """
-
- if value.startswith('testgit::'):
- value = value[9:]
-
- return value
-
-
-def read_one_line(repo):
- """Reads and processes one command.
- """
-
- sleepy = os.environ.get("GIT_REMOTE_TESTGIT_SLEEPY")
- if sleepy:
- debug("Sleeping %d sec before readline" % int(sleepy))
- time.sleep(int(sleepy))
-
- line = sys.stdin.readline()
-
- cmdline = line
-
- if not cmdline:
- warn("Unexpected EOF")
- return False
-
- cmdline = cmdline.strip().split()
- if not cmdline:
- # Blank line means we're about to quit
- return False
-
- cmd = cmdline.pop(0)
- debug("Got command '%s' with args '%s'", cmd, ' '.join(cmdline))
-
- if cmd not in COMMANDS:
- die("Unknown command, %s", cmd)
-
- func = COMMANDS[cmd]
- func(repo, cmdline)
- sys.stdout.flush()
-
- return True
-
-
-def main(args):
- """Starts a new remote helper for the specified repository.
- """
-
- if len(args) != 3:
- die("Expecting exactly three arguments.")
- sys.exit(1)
-
- if os.getenv("GIT_DEBUG_TESTGIT"):
- import git_remote_helpers.util
- git_remote_helpers.util.DEBUG = True
-
- alias = sanitize(args[1])
- url = sanitize(args[2])
-
- if not alias.isalnum():
- warn("non-alnum alias '%s'", alias)
- alias = "tmp"
-
- args[1] = alias
- args[2] = url
-
- repo = get_repo(alias, url)
-
- debug("Got arguments %s", args[1:])
-
- more = True
-
- sys.stdin = os.fdopen(sys.stdin.fileno(), 'r', 0)
- while (more):
- more = read_one_line(repo)
-
-if __name__ == '__main__':
- sys.exit(main(sys.argv))
diff --git a/git-remote-testpy.py b/git-remote-testpy.py
new file mode 100644
index 0000000..ade797b
--- /dev/null
+++ b/git-remote-testpy.py
@@ -0,0 +1,272 @@
+#!/usr/bin/env python
+
+# This command is a simple remote-helper, that is used both as a
+# testcase for the remote-helper functionality, and as an example to
+# show remote-helper authors one possible implementation.
+#
+# This is a Git <-> Git importer/exporter, that simply uses git
+# fast-import and git fast-export to consume and produce fast-import
+# streams.
+#
+# To understand better the way things work, one can activate debug
+# traces by setting (to any value) the environment variables
+# GIT_TRANSPORT_HELPER_DEBUG and GIT_DEBUG_TESTGIT, to see messages
+# from the transport-helper side, or from this example remote-helper.
+
+# hashlib is only available in python >= 2.5
+try:
+ import hashlib
+ _digest = hashlib.sha1
+except ImportError:
+ import sha
+ _digest = sha.new
+import sys
+import os
+import time
+sys.path.insert(0, os.getenv("GITPYTHONLIB","."))
+
+from git_remote_helpers.util import die, debug, warn
+from git_remote_helpers.git.repo import GitRepo
+from git_remote_helpers.git.exporter import GitExporter
+from git_remote_helpers.git.importer import GitImporter
+from git_remote_helpers.git.non_local import NonLocalGit
+
+def get_repo(alias, url):
+ """Returns a git repository object initialized for usage.
+ """
+
+ repo = GitRepo(url)
+ repo.get_revs()
+ repo.get_head()
+
+ hasher = _digest()
+ hasher.update(repo.path)
+ repo.hash = hasher.hexdigest()
+
+ repo.get_base_path = lambda base: os.path.join(
+ base, 'info', 'fast-import', repo.hash)
+
+ prefix = 'refs/testgit/%s/' % alias
+ debug("prefix: '%s'", prefix)
+
+ repo.gitdir = os.environ["GIT_DIR"]
+ repo.alias = alias
+ repo.prefix = prefix
+
+ repo.exporter = GitExporter(repo)
+ repo.importer = GitImporter(repo)
+ repo.non_local = NonLocalGit(repo)
+
+ return repo
+
+
+def local_repo(repo, path):
+ """Returns a git repository object initalized for usage.
+ """
+
+ local = GitRepo(path)
+
+ local.non_local = None
+ local.gitdir = repo.gitdir
+ local.alias = repo.alias
+ local.prefix = repo.prefix
+ local.hash = repo.hash
+ local.get_base_path = repo.get_base_path
+ local.exporter = GitExporter(local)
+ local.importer = GitImporter(local)
+
+ return local
+
+
+def do_capabilities(repo, args):
+ """Prints the supported capabilities.
+ """
+
+ print "import"
+ print "export"
+ print "refspec refs/heads/*:%s*" % repo.prefix
+
+ dirname = repo.get_base_path(repo.gitdir)
+
+ if not os.path.exists(dirname):
+ os.makedirs(dirname)
+
+ path = os.path.join(dirname, 'git.marks')
+
+ print "*export-marks %s" % path
+ if os.path.exists(path):
+ print "*import-marks %s" % path
+
+ print # end capabilities
+
+
+def do_list(repo, args):
+ """Lists all known references.
+
+ Bug: This will always set the remote head to master for non-local
+ repositories, since we have no way of determining what the remote
+ head is at clone time.
+ """
+
+ for ref in repo.revs:
+ debug("? refs/heads/%s", ref)
+ print "? refs/heads/%s" % ref
+
+ if repo.head:
+ debug("@refs/heads/%s HEAD" % repo.head)
+ print "@refs/heads/%s HEAD" % repo.head
+ else:
+ debug("@refs/heads/master HEAD")
+ print "@refs/heads/master HEAD"
+
+ print # end list
+
+
+def update_local_repo(repo):
+ """Updates (or clones) a local repo.
+ """
+
+ if repo.local:
+ return repo
+
+ path = repo.non_local.clone(repo.gitdir)
+ repo.non_local.update(repo.gitdir)
+ repo = local_repo(repo, path)
+ return repo
+
+
+def do_import(repo, args):
+ """Exports a fast-import stream from testgit for git to import.
+ """
+
+ if len(args) != 1:
+ die("Import needs exactly one ref")
+
+ if not repo.gitdir:
+ die("Need gitdir to import")
+
+ ref = args[0]
+ refs = [ref]
+
+ while True:
+ line = sys.stdin.readline()
+ if line == '\n':
+ break
+ if not line.startswith('import '):
+ die("Expected import line.")
+
+ # strip of leading 'import '
+ ref = line[7:].strip()
+ refs.append(ref)
+
+ repo = update_local_repo(repo)
+ repo.exporter.export_repo(repo.gitdir, refs)
+
+ print "done"
+
+
+def do_export(repo, args):
+ """Imports a fast-import stream from git to testgit.
+ """
+
+ if not repo.gitdir:
+ die("Need gitdir to export")
+
+ update_local_repo(repo)
+ changed = repo.importer.do_import(repo.gitdir)
+
+ if not repo.local:
+ repo.non_local.push(repo.gitdir)
+
+ for ref in changed:
+ print "ok %s" % ref
+ print
+
+
+COMMANDS = {
+ 'capabilities': do_capabilities,
+ 'list': do_list,
+ 'import': do_import,
+ 'export': do_export,
+}
+
+
+def sanitize(value):
+ """Cleans up the url.
+ """
+
+ if value.startswith('testgit::'):
+ value = value[9:]
+
+ return value
+
+
+def read_one_line(repo):
+ """Reads and processes one command.
+ """
+
+ sleepy = os.environ.get("GIT_REMOTE_TESTGIT_SLEEPY")
+ if sleepy:
+ debug("Sleeping %d sec before readline" % int(sleepy))
+ time.sleep(int(sleepy))
+
+ line = sys.stdin.readline()
+
+ cmdline = line
+
+ if not cmdline:
+ warn("Unexpected EOF")
+ return False
+
+ cmdline = cmdline.strip().split()
+ if not cmdline:
+ # Blank line means we're about to quit
+ return False
+
+ cmd = cmdline.pop(0)
+ debug("Got command '%s' with args '%s'", cmd, ' '.join(cmdline))
+
+ if cmd not in COMMANDS:
+ die("Unknown command, %s", cmd)
+
+ func = COMMANDS[cmd]
+ func(repo, cmdline)
+ sys.stdout.flush()
+
+ return True
+
+
+def main(args):
+ """Starts a new remote helper for the specified repository.
+ """
+
+ if len(args) != 3:
+ die("Expecting exactly three arguments.")
+ sys.exit(1)
+
+ if os.getenv("GIT_DEBUG_TESTGIT"):
+ import git_remote_helpers.util
+ git_remote_helpers.util.DEBUG = True
+
+ alias = sanitize(args[1])
+ url = sanitize(args[2])
+
+ if not alias.isalnum():
+ warn("non-alnum alias '%s'", alias)
+ alias = "tmp"
+
+ args[1] = alias
+ args[2] = url
+
+ repo = get_repo(alias, url)
+
+ debug("Got arguments %s", args[1:])
+
+ more = True
+
+ sys.stdin = os.fdopen(sys.stdin.fileno(), 'r', 0)
+ while (more):
+ more = read_one_line(repo)
+
+if __name__ == '__main__':
+ sys.exit(main(sys.argv))
diff --git a/t/t5800-remote-helpers.sh b/t/t5800-remote-helpers.sh
deleted file mode 100755
index d46fa40..0000000
--- a/t/t5800-remote-helpers.sh
+++ /dev/null
@@ -1,148 +0,0 @@
-#!/bin/sh
-#
-# Copyright (c) 2010 Sverre Rabbelier
-#
-
-test_description='Test remote-helper import and export commands'
-
-. ./test-lib.sh
-
-if ! test_have_prereq PYTHON ; then
- skip_all='skipping remote-testgit tests, python not available'
- test_done
-fi
-
-"$PYTHON_PATH" -c '
-import sys
-if sys.hexversion < 0x02040000:
- sys.exit(1)
-' || {
- skip_all='skipping remote-testgit tests, python version < 2.4'
- test_done
-}
-
-compare_refs() {
- git --git-dir="$1/.git" rev-parse --verify $2 >expect &&
- git --git-dir="$3/.git" rev-parse --verify $4 >actual &&
- test_cmp expect actual
-}
-
-test_expect_success 'setup repository' '
- git init --bare server/.git &&
- git clone server public &&
- (cd public &&
- echo content >file &&
- git add file &&
- git commit -m one &&
- git push origin master)
-'
-
-test_expect_success 'cloning from local repo' '
- git clone "testgit::${PWD}/server" localclone &&
- test_cmp public/file localclone/file
-'
-
-test_expect_success 'cloning from remote repo' '
- git clone "testgit::file://${PWD}/server" clone &&
- test_cmp public/file clone/file
-'
-
-test_expect_success 'create new commit on remote' '
- (cd public &&
- echo content >>file &&
- git commit -a -m two &&
- git push)
-'
-
-test_expect_success 'pulling from local repo' '
- (cd localclone && git pull) &&
- test_cmp public/file localclone/file
-'
-
-test_expect_success 'pulling from remote remote' '
- (cd clone && git pull) &&
- test_cmp public/file clone/file
-'
-
-test_expect_success 'pushing to local repo' '
- (cd localclone &&
- echo content >>file &&
- git commit -a -m three &&
- git push) &&
- compare_refs localclone HEAD server HEAD
-'
-
-# Generally, skip this test. It demonstrates a now-fixed race in
-# git-remote-testgit, but is too slow to leave in for general use.
-: test_expect_success 'racily pushing to local repo' '
- test_when_finished "rm -rf server2 localclone2" &&
- cp -R server server2 &&
- git clone "testgit::${PWD}/server2" localclone2 &&
- (cd localclone2 &&
- echo content >>file &&
- git commit -a -m three &&
- GIT_REMOTE_TESTGIT_SLEEPY=2 git push) &&
- compare_refs localclone2 HEAD server2 HEAD
-'
-
-test_expect_success 'synch with changes from localclone' '
- (cd clone &&
- git pull)
-'
-
-test_expect_success 'pushing remote local repo' '
- (cd clone &&
- echo content >>file &&
- git commit -a -m four &&
- git push) &&
- compare_refs clone HEAD server HEAD
-'
-
-test_expect_success 'fetch new branch' '
- (cd public &&
- git checkout -b new &&
- echo content >>file &&
- git commit -a -m five &&
- git push origin new
- ) &&
- (cd localclone &&
- git fetch origin new
- ) &&
- compare_refs public HEAD localclone FETCH_HEAD
-'
-
-test_expect_success 'fetch multiple branches' '
- (cd localclone &&
- git fetch
- ) &&
- compare_refs server master localclone refs/remotes/origin/master &&
- compare_refs server new localclone refs/remotes/origin/new
-'
-
-test_expect_success 'push when remote has extra refs' '
- (cd clone &&
- echo content >>file &&
- git commit -a -m six &&
- git push
- ) &&
- compare_refs clone master server master
-'
-
-test_expect_success 'push new branch by name' '
- (cd clone &&
- git checkout -b new-name &&
- echo content >>file &&
- git commit -a -m seven &&
- git push origin new-name
- ) &&
- compare_refs clone HEAD server refs/heads/new-name
-'
-
-test_expect_failure 'push new branch with old:new refspec' '
- (cd clone &&
- git push origin new-name:new-refspec
- ) &&
- compare_refs clone HEAD server refs/heads/new-refspec
-'
-
-test_done
diff --git a/t/t5800-remote-testpy.sh b/t/t5800-remote-testpy.sh
new file mode 100755
index 0000000..6750961
--- /dev/null
+++ b/t/t5800-remote-testpy.sh
@@ -0,0 +1,148 @@
+#!/bin/sh
+#
+# Copyright (c) 2010 Sverre Rabbelier
+#
+
+test_description='Test python remote-helper framework'
+
+. ./test-lib.sh
+
+if ! test_have_prereq PYTHON ; then
+ skip_all='skipping python remote-helper tests, python not available'
+ test_done
+fi
+
+"$PYTHON_PATH" -c '
+import sys
+if sys.hexversion < 0x02040000:
+ sys.exit(1)
+' || {
+ skip_all='skipping python remote-helper tests, python version < 2.4'
+ test_done
+}
+
+compare_refs() {
+ git --git-dir="$1/.git" rev-parse --verify $2 >expect &&
+ git --git-dir="$3/.git" rev-parse --verify $4 >actual &&
+ test_cmp expect actual
+}
+
+test_expect_success 'setup repository' '
+ git init --bare server/.git &&
+ git clone server public &&
+ (cd public &&
+ echo content >file &&
+ git add file &&
+ git commit -m one &&
+ git push origin master)
+'
+
+test_expect_success 'cloning from local repo' '
+ git clone "testpy::${PWD}/server" localclone &&
+ test_cmp public/file localclone/file
+'
+
+test_expect_success 'cloning from remote repo' '
+ git clone "testpy::file://${PWD}/server" clone &&
+ test_cmp public/file clone/file
+'
+
+test_expect_success 'create new commit on remote' '
+ (cd public &&
+ echo content >>file &&
+ git commit -a -m two &&
+ git push)
+'
+
+test_expect_success 'pulling from local repo' '
+ (cd localclone && git pull) &&
+ test_cmp public/file localclone/file
+'
+
+test_expect_success 'pulling from remote remote' '
+ (cd clone && git pull) &&
+ test_cmp public/file clone/file
+'
+
+test_expect_success 'pushing to local repo' '
+ (cd localclone &&
+ echo content >>file &&
+ git commit -a -m three &&
+ git push) &&
+ compare_refs localclone HEAD server HEAD
+'
+
+# Generally, skip this test. It demonstrates a now-fixed race in
+# git-remote-testpy, but is too slow to leave in for general use.
+: test_expect_success 'racily pushing to local repo' '
+ test_when_finished "rm -rf server2 localclone2" &&
+ cp -R server server2 &&
+ git clone "testpy::${PWD}/server2" localclone2 &&
+ (cd localclone2 &&
+ echo content >>file &&
+ git commit -a -m three &&
+ GIT_REMOTE_TESTGIT_SLEEPY=2 git push) &&
+ compare_refs localclone2 HEAD server2 HEAD
+'
+
+test_expect_success 'synch with changes from localclone' '
+ (cd clone &&
+ git pull)
+'
+
+test_expect_success 'pushing remote local repo' '
+ (cd clone &&
+ echo content >>file &&
+ git commit -a -m four &&
+ git push) &&
+ compare_refs clone HEAD server HEAD
+'
+
+test_expect_success 'fetch new branch' '
+ (cd public &&
+ git checkout -b new &&
+ echo content >>file &&
+ git commit -a -m five &&
+ git push origin new
+ ) &&
+ (cd localclone &&
+ git fetch origin new
+ ) &&
+ compare_refs public HEAD localclone FETCH_HEAD
+'
+
+test_expect_success 'fetch multiple branches' '
+ (cd localclone &&
+ git fetch
+ ) &&
+ compare_refs server master localclone refs/remotes/origin/master &&
+ compare_refs server new localclone refs/remotes/origin/new
+'
+
+test_expect_success 'push when remote has extra refs' '
+ (cd clone &&
+ echo content >>file &&
+ git commit -a -m six &&
+ git push
+ ) &&
+ compare_refs clone master server master
+'
+
+test_expect_success 'push new branch by name' '
+ (cd clone &&
+ git checkout -b new-name &&
+ echo content >>file &&
+ git commit -a -m seven &&
+ git push origin new-name
+ ) &&
+ compare_refs clone HEAD server refs/heads/new-name
+'
+
+test_expect_failure 'push new branch with old:new refspec' '
+ (cd clone &&
+ git push origin new-name:new-refspec
+ ) &&
+ compare_refs clone HEAD server refs/heads/new-refspec
+'
+
+test_done
--
1.8.0
^ permalink raw reply related
* [PATCH v5 02/15] remote-testgit: fix direction of marks
From: Felipe Contreras @ 2012-11-11 13:59 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Johannes Schindelin, Max Horn, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips, Felipe Contreras
In-Reply-To: <1352642392-28387-1-git-send-email-felipe.contreras@gmail.com>
Basically this is what we want:
== pull ==
testgit transport-helper
* export -> import
# testgit.marks git.marks
== push ==
testgit transport-helper
* import <- export
# testgit.marks git.marks
Each side should be agnostic of the other side. Because testgit.marks
(our helper marks) could be anything, not necesarily a format parsable
by fast-export or fast-import. In this test hey happen to be compatible,
because we use those tools, but in the real world it would be something
compelely different. For example, they might be mapping marks to
mercurial revisions (certainly not parsable by fast-import/export).
This is what we have:
== pull ==
testgit transport-helper
* export -> import
# testgit.marks git.marks
== push ==
testgit transport-helper
* import <- export
# git.marks testgit.marks
The only reason this is working is that git.marks and testgit.marks are
roughly the same.
This new behavior used to not be possible before due to a bug in
fast-export, but with the bug fixed, it works fine.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
git-remote-testgit.py | 2 +-
git_remote_helpers/git/importer.py | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-remote-testgit.py b/git-remote-testgit.py
index 5f3ebd2..ade797b 100644
--- a/git-remote-testgit.py
+++ b/git-remote-testgit.py
@@ -91,7 +91,7 @@ def do_capabilities(repo, args):
if not os.path.exists(dirname):
os.makedirs(dirname)
- path = os.path.join(dirname, 'testgit.marks')
+ path = os.path.join(dirname, 'git.marks')
print "*export-marks %s" % path
if os.path.exists(path):
diff --git a/git_remote_helpers/git/importer.py b/git_remote_helpers/git/importer.py
index 5c6b595..e28cc8f 100644
--- a/git_remote_helpers/git/importer.py
+++ b/git_remote_helpers/git/importer.py
@@ -39,7 +39,7 @@ class GitImporter(object):
gitdir = self.repo.gitpath
else:
gitdir = os.path.abspath(os.path.join(dirname, '.git'))
- path = os.path.abspath(os.path.join(dirname, 'git.marks'))
+ path = os.path.abspath(os.path.join(dirname, 'testgit.marks'))
if not os.path.exists(dirname):
os.makedirs(dirname)
--
1.8.0
^ permalink raw reply related
* [PATCH v5 03/15] remote-helpers: fix failure message
From: Felipe Contreras @ 2012-11-11 13:59 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Johannes Schindelin, Max Horn, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips, Felipe Contreras
In-Reply-To: <1352642392-28387-1-git-send-email-felipe.contreras@gmail.com>
This is remote-testgit, not remote-hg.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
t/t5800-remote-helpers.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t5800-remote-helpers.sh b/t/t5800-remote-helpers.sh
index e7dc668..d46fa40 100755
--- a/t/t5800-remote-helpers.sh
+++ b/t/t5800-remote-helpers.sh
@@ -8,7 +8,7 @@ test_description='Test remote-helper import and export commands'
. ./test-lib.sh
if ! test_have_prereq PYTHON ; then
- skip_all='skipping git-remote-hg tests, python not available'
+ skip_all='skipping remote-testgit tests, python not available'
test_done
fi
@@ -17,7 +17,7 @@ import sys
if sys.hexversion < 0x02040000:
sys.exit(1)
' || {
- skip_all='skipping git-remote-hg tests, python version < 2.4'
+ skip_all='skipping remote-testgit tests, python version < 2.4'
test_done
}
--
1.8.0
^ permalink raw reply related
* [PATCH v5 01/15] fast-export: avoid importing blob marks
From: Felipe Contreras @ 2012-11-11 13:59 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Johannes Schindelin, Max Horn, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips, Felipe Contreras
In-Reply-To: <1352642392-28387-1-git-send-email-felipe.contreras@gmail.com>
We want to be able to import, and then export, using the same marks, so
that we don't push things that the other side already received.
Unfortunately, fast-export doesn't store blobs in the marks, but
fast-import does. This creates a mismatch when fast export is reusing a
mark that was previously stored by fast-import.
There is no point in one tool saving blobs, and the other not, but for
now let's just check in fast-export that the objects are indeed commits.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
builtin/fast-export.c | 4 ++++
t/t9350-fast-export.sh | 14 ++++++++++++++
2 files changed, 18 insertions(+)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index 12220ad..a06fe10 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -614,6 +614,10 @@ static void import_marks(char *input_file)
if (object->flags & SHOWN)
error("Object %s already has a mark", sha1_to_hex(sha1));
+ if (object->type != 1)
+ /* only commits */
+ continue;
+
mark_object(object, mark);
if (last_idnum < mark)
last_idnum = mark;
diff --git a/t/t9350-fast-export.sh b/t/t9350-fast-export.sh
index 3e821f9..0c8d828 100755
--- a/t/t9350-fast-export.sh
+++ b/t/t9350-fast-export.sh
@@ -440,4 +440,18 @@ test_expect_success 'fast-export quotes pathnames' '
)
'
+test_expect_success 'test biridectionality' '
+ echo -n > marks-cur &&
+ echo -n > marks-new &&
+ git init marks-test &&
+ git fast-export --export-marks=marks-cur --import-marks=marks-cur --branches | \
+ git --git-dir=marks-test/.git fast-import --export-marks=marks-new --import-marks=marks-new &&
+ (cd marks-test &&
+ git reset --hard &&
+ echo Wohlauf > file &&
+ git commit -a -m "back in time") &&
+ git --git-dir=marks-test/.git fast-export --export-marks=marks-new --import-marks=marks-new --branches | \
+ git fast-import --export-marks=marks-cur --import-marks=marks-cur
+'
+
test_done
--
1.8.0
^ permalink raw reply related
* [PATCH v5 00/15] fast-export and remote-testgit improvements
From: Felipe Contreras @ 2012-11-11 13:59 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Johannes Schindelin, Max Horn, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips, Felipe Contreras
Hi,
Basically resending with a few fixes...
I found more issues in fast-export. remote-testgit, and eventually I decided
there's no reason to use this python script, so I wrote a much simpler version
that does the same, and more. I'm not going to list all the reasons because
apparently opinions are not welcome in the list any more. For the actual
differences you can check the patch itself.
The old remote-testgit is now remote-testpy (as it's testing the python
framework, not really remote helpers). The tests are simplified, and exercise
more features of transport-helper, and unsuprisingly, find more bugs.
Some of these bugs are fixed in this patch series as well, for which I already
sent 3 versions, and they come at the end. I was surprised they did fix them,
but hey... good is good.
I know how to fix the rest of the issues, but I'm not going to bother sending a
patch because obvious... er, simple? fixes are not accepted, so there's no
chance of something less... evident? getting through.
Cheers.
Changes since v4:
* Add check for bash in test
* Avoid bash associative arrays for older versions
* Apply trivial comments
* White-space cleanups
Felipe Contreras (15):
fast-export: avoid importing blob marks
remote-testgit: fix direction of marks
remote-helpers: fix failure message
Rename git-remote-testgit to git-remote-testpy
Add new simplified git-remote-testgit
remote-testgit: get rid of non-local functionality
remote-testgit: remove irrelevant test
remote-testgit: cleanup tests
remote-testgit: exercise more features
remote-testgit: report success after an import
remote-testgit: make clear the 'done' feature
fast-export: trivial cleanup
fast-export: fix comparison in tests
fast-export: make sure updated refs get updated
fast-export: don't handle uninteresting refs
.gitignore | 2 +-
Documentation/git-remote-testgit.txt | 2 +-
Makefile | 2 +-
builtin/fast-export.c | 20 ++-
git-remote-testgit | 82 +++++++++++
git-remote-testgit.py | 272 -----------------------------------
git-remote-testpy.py | 272 +++++++++++++++++++++++++++++++++++
git_remote_helpers/git/importer.py | 2 +-
t/t5800-remote-helpers.sh | 148 -------------------
t/t5800-remote-testpy.sh | 148 +++++++++++++++++++
t/t5801-remote-helpers.sh | 158 ++++++++++++++++++++
t/t9350-fast-export.sh | 41 +++++-
12 files changed, 717 insertions(+), 432 deletions(-)
create mode 100755 git-remote-testgit
delete mode 100644 git-remote-testgit.py
create mode 100644 git-remote-testpy.py
delete mode 100755 t/t5800-remote-helpers.sh
create mode 100755 t/t5800-remote-testpy.sh
create mode 100644 t/t5801-remote-helpers.sh
--
1.8.0
^ permalink raw reply
* [PATCH try3] completion: use more proper emulation for zsh
From: Felipe Contreras @ 2012-11-11 13:51 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras, Junio C Hamano, Mark Lodato
It turns out there's no 'bash' emulation in zsh. Anything that starts
with a 'b' is mapped to the 'sh' emulation, presumably because of
_b_ourne shell.
kzh emulation seems closer to bash, and at least I haven't had problems
with this.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
This is the third time I send this patch.
contrib/completion/git-completion.bash | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index be800e0..d7439a5 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2432,8 +2432,7 @@ __gitk_main ()
__git_func_wrap ()
{
if [[ -n ${ZSH_VERSION-} ]]; then
- emulate -L bash
- setopt KSH_TYPESET
+ emulate -L ksh
# workaround zsh's bug that leaves 'words' as a special
# variable in versions < 4.3.12
--
1.8.0
^ permalink raw reply related
* Re: Reviews on mailing-list
From: Felipe Contreras @ 2012-11-11 13:40 UTC (permalink / raw)
To: Thiago Farina; +Cc: Deniz Türkoglu, git, Junio C Hamano, Shawn Pearce
In-Reply-To: <CACnwZYfP4=Fvt8T0GOEzjTOaEyYF_Ao6e_f02eqO_5_DyzM0Zw@mail.gmail.com>
On Sun, Nov 11, 2012 at 2:09 PM, Thiago Farina <tfransosi@gmail.com> wrote:
> On Sun, Nov 11, 2012 at 10:14 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> Requiring everyone to use a web browser would limit the amount of ways
>> people can review patches.
> I don't see that as a limitation as I think everyone has access to a
> web browser these days, don't have?
>
>>> How come that can
>>> be an impediment to move forward way of this awkward way of reviewing
>>> patches through email?
>>
>> It's not awkward, it's the most sensible way.
>>
> The most harder way I think?
>
> Look at this:
> https://gerrit.chromium.org/gerrit/#/q/status:open+project:chromiumos/platform/power_manager,n,z
>
> There I can go and see many informations that through this mailing
> list I can't or have to do much more work in order to archive this.
That information has nothing to do with reviews. That's patch state-tracking.
> If you open one of the 'patches' you can see some relevant information:
> - Who is the owner/author
> - Was it verified?
> - Is it ready for landing?
Irrelevant for git.
> - If I click on Side-by-side I get a nice diff view interface that
> plan text email does NOT give me.
Not useful.
> - Was it reviewed/approved (+1, +2)?
You can see the same in a mail thread.
> - It can be merged by one click.
Irrelevant for git.
> - The interface also provide the command line to download/apply the
> patch for me.
Not useful.
> - Isn't there a reason (implicit there) for Google being using tools
> like Gerrit/CodeReview(rietveld)/Mondrian for handling his code
> reviews rather than solely by 'email'?
Who knows And if there is, who knows if it's valid.
And none of those points has anything to do with code *review*.
All these points are about state-tracking, and that can be implemented
*on top* of the mailing list, for example through patchwork:
http://patchwork.newartisans.com/patch/1531/
That's if somebody actually cared about that, but that doesn't seem to
be the case.
>> You just replied to my mail the same way I would reply to a patch.
>>
> I replied through a web browser by the Gmail interface. ;)
Indeed, Gmail is one of the many ways you can review a patch.
You clik reply, you add the comments in line, and click send. Couldn't
be easier.
>>> There are a lot of issues of having to use email for reviewing patches
>>> that I think Gerrit is a superior alternative.
>>
>> There are no issues. It works for Linux, qemu, libav, ffmpeg, git, and
>> many other projects.
>>
>>> And many people are arguing for it!
>>
>> Nope, they are not.
>>
> If they weren't then nobody would be suggesting to use Gerrit for
> handling the review of git patches.
Except you, of course.
> But I think the big resistance comes from the fact that the core
> developers handle/review the git patches through Gnus/Emacs, so that
> is enough for them and they don't want to make the switch because of
> that?
gnus/emacs/notmuch/thunderbird/Gmail, and pretty much every mail
client out there.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Reviews on mailing-list
From: Thiago Farina @ 2012-11-11 13:09 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Deniz Türkoglu, git, Junio C Hamano, Shawn Pearce
In-Reply-To: <CAMP44s2P-nhAGgj9nuJ3cKqb6+enAthwiUNS8QTZn8MP1poJ2g@mail.gmail.com>
On Sun, Nov 11, 2012 at 10:14 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> Requiring everyone to use a web browser would limit the amount of ways
> people can review patches.
I don't see that as a limitation as I think everyone has access to a
web browser these days, don't have?
>> How come that can
>> be an impediment to move forward way of this awkward way of reviewing
>> patches through email?
>
> It's not awkward, it's the most sensible way.
>
The most harder way I think?
Look at this:
https://gerrit.chromium.org/gerrit/#/q/status:open+project:chromiumos/platform/power_manager,n,z
There I can go and see many informations that through this mailing
list I can't or have to do much more work in order to archive this.
If you open one of the 'patches' you can see some relevant information:
- Who is the owner/author
- Was it verified?
- Is it ready for landing?
- If I click on Side-by-side I get a nice diff view interface that
plan text email does NOT give me.
- Was it reviewed/approved (+1, +2)?
- It can be merged by one click.
- The interface also provide the command line to download/apply the
patch for me.
- Isn't there a reason (implicit there) for Google being using tools
like Gerrit/CodeReview(rietveld)/Mondrian for handling his code
reviews rather than solely by 'email'?
> You just replied to my mail the same way I would reply to a patch.
>
I replied through a web browser by the Gmail interface. ;)
>> There are a lot of issues of having to use email for reviewing patches
>> that I think Gerrit is a superior alternative.
>
> There are no issues. It works for Linux, qemu, libav, ffmpeg, git, and
> many other projects.
>
>> And many people are arguing for it!
>
> Nope, they are not.
>
If they weren't then nobody would be suggesting to use Gerrit for
handling the review of git patches.
But I think the big resistance comes from the fact that the core
developers handle/review the git patches through Gnus/Emacs, so that
is enough for them and they don't want to make the switch because of
that?
^ permalink raw reply
* Re: [PATCH] custom log formats for "diff --submodule=log"
From: Ramkumar Ramachandra @ 2012-11-11 13:05 UTC (permalink / raw)
To: Jeff King; +Cc: git, Jeffrey S. Haemer
In-Reply-To: <CALkWK0mYs7Q1256gY7ZH3Ng3xbYv2+XVHCZ7XYWgWUp2O-VzqQ@mail.gmail.com>
Hi again,
Ramkumar Ramachandra wrote:
> Don't you mean `git diff` in place of `git log -p`
> though? I don't think `git log --submodule` does anything differently
> from `git log`.
Sorry for the nonsense. I just realized that it affects the diffs
shown by `git log -p`.
Ram
^ permalink raw reply
* Re: [PATCH] contrib/remote-helpers: setup ui.username in test-hg.sh
From: Ramkumar Ramachandra @ 2012-11-11 12:50 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Git List, Jeff King
In-Reply-To: <CAMP44s3cx9EHfM7wEX3zV-MXqX11VusYj8W9cL63mFTUq+_C+Q@mail.gmail.com>
Felipe Contreras wrote:
> On Sun, Nov 11, 2012 at 11:41 AM, Ramkumar Ramachandra
> <artagnon@gmail.com> wrote:
>> test-hg.sh forgets to set ui.username, which is required for `hg
>> commit`. Fix this.
>
> Hmm, I get 'no username found, using 'felipec@nysa' instead', but
> everything works fine.
I get:
abort: no username supplied (see "hg help config")
And the test aborts.
Ram
^ permalink raw reply
* Re: Test failures in contrib/remote-helpers
From: Ramkumar Ramachandra @ 2012-11-11 12:48 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Git List
In-Reply-To: <CAMP44s1TLyKoHVouwgCFqi-vwA6rUBYJZXTA7JDFX6bfyQ7_tw@mail.gmail.com>
Felipe Contreras wrote:
> On Sun, Nov 11, 2012 at 11:32 AM, Ramkumar Ramachandra
> <artagnon@gmail.com> wrote:
>> I'm experiencing test failures in contrib/remote-helpers.
>
> Which are your versions of hg, and bzr?
Mercurial Distributed SCM (version 1.9.1)
Bazaar (bzr) 2.4.1
Ram
^ permalink raw reply
* Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
From: Felipe Contreras @ 2012-11-11 12:41 UTC (permalink / raw)
To: gitzilla; +Cc: Michael J Gruber, Git Mailing List, Jeff King
In-Reply-To: <509EAA45.8020005@gmail.com>
On Sat, Nov 10, 2012 at 8:25 PM, A Large Angry SCM <gitzilla@gmail.com> wrote:
> On 11/10/2012 01:43 PM, Felipe Contreras wrote:
>> So, the options are:
>>
>> a) Leave the name conversion to the export tools, and when they miss
>> some weird corner case, like 'Author<email', let the user face the
>> consequences, perhaps after an hour of the process.
>>
>> We know there are sources of data that don't have git-formatted author
>> names, so we know every tool out there must do this checking.
>>
>> In addition to that, let the export tool decide what to do when one of
>> these bad names appear, which in many cases probably means do nothing,
>> so the user would not even see that such a bad name was there, which
>> might not be what they want.
>>
>> b) Do the name conversion in fast-import itself, perhaps optionally,
>> so if a tool missed some weird corner case, the user does not have to
>> face the consequences.
>>
>> The tool writers don't have to worry about this, so we would not have
>> tools out there doing a half-assed job of this.
>>
>> And what happens when such bad names end up being consistent: warning,
>> a scaffold mapping of bad names, etc.
>>
>>
>> One is bad for the users, and the tools writers, only disadvantages,
>> the other is good for the users and the tools writers, only
>> advantages.
>>
>
> c) Do the name conversion, and whatever other cleanup and manipulations
> you're interesting in, in a filter between the exporter and git-fast-import.
Such a filter would probably be quite complicated, and would decrease
performance.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] contrib/remote-helpers: setup ui.username in test-hg.sh
From: Felipe Contreras @ 2012-11-11 12:39 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Jeff King
In-Reply-To: <CALkWK0kguFpA3ExSt7YKtugWq-0FvNQ=QFaKUo6uUjt8+=5mfw@mail.gmail.com>
On Sun, Nov 11, 2012 at 11:41 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> test-hg.sh forgets to set ui.username, which is required for `hg
> commit`. Fix this.
Hmm, I get 'no username found, using 'felipec@nysa' instead', but
everything works fine.
Doesn't hurt to do that though.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Reviews on mailing-list
From: Felipe Contreras @ 2012-11-11 12:24 UTC (permalink / raw)
To: Deniz Türkoglu; +Cc: git, Junio C Hamano, Shawn Pearce
In-Reply-To: <CA+ZXwZO8tpGi7_njbFx6w2ZAWoySVb2Bcc+DSupLenKrNAGV_A@mail.gmail.com>
On Sun, Nov 11, 2012 at 2:28 AM, Deniz Türkoglu <deniz@spotify.com> wrote:
> On Sat, Nov 10, 2012 at 3:40 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Sun, Nov 11, 2012 at 12:19 AM, Deniz Türkoglu <deniz@spotify.com> wrote:
>>
>>> This is my first mail to the git mailing list. I have been following
>>> the list for some time now and I would like to suggest moving the
>>> reviews out of the mailing list, for example to a gerrit instance, I
>>> believe it would improve the commits and the mailing list. I have a
>>> filter on 'PATCH', but I feel I miss some of the discussion, and
>>> things that I would be interested in.
>>>
>>> I have spoken to Shawn Pearce (gerrit project lead, google) and he
>>> said he is OK with hosting the gerrit instance.
>>>
>>> I would like to hear your thoughts on this.
>>
>> Personally I think reviews on the mailing list is far superior than
>> any other review methods. I've even blogged about it and all the
>> reasons[1]. Gerrit is better than bugzilla, but it still requires a
>> web browser, and logging in.
>
> I disagree that the current approach is optimal. Bugzilla is a
> bug-tracker and is not meant to be used for reviews. I believe in
> using the right tool for the right job. An e-mail should be concise
> and to the point, in this case only contain the discussion. This will
> help it to reach a wider audience and be more useful when people
> stumble upon it through a google search.
I don't understand what you are saying. If you google 'git reviews on
mailing lit', you will find results like this:
http://article.gmane.org/gmane.comp.version-control.git/209313
You don't get any patches because you didn't search for patches, and
either way Google would not filter out the results from gerrit either.
For example: googing 'cyanogenmod "Remove tabs from GNexusParts" will
throw:
http://review.cyanogenmod.org/
--
Felipe Contreras
^ permalink raw reply
* Re: Reviews on mailing-list
From: Felipe Contreras @ 2012-11-11 12:14 UTC (permalink / raw)
To: Thiago Farina; +Cc: Deniz Türkoglu, git, Junio C Hamano, Shawn Pearce
In-Reply-To: <CACnwZYekU0CYnqQT8L2siJbUsn=T9qowgth94TWc8KN472Ziag@mail.gmail.com>
On Sun, Nov 11, 2012 at 2:13 AM, Thiago Farina <tfransosi@gmail.com> wrote:
> On Sat, Nov 10, 2012 at 9:40 PM, Felipe Contreras
>> Personally I think reviews on the mailing list is far superior than
>> any other review methods. I've even blogged about it and all the
>> reasons[1]. Gerrit is better than bugzilla, but it still requires a
>> web browser, and logging in.
>>
> Requiring a web browser is a huge requirement, ham??
Yes. Today people can use any mail interface: web, console-based,
graphical. They can use Gmail clients in their phone, or IMAP, or
whatever.
Requiring everyone to use a web browser would limit the amount of ways
people can review patches. Also, not everyone has javascript enabled
in their browser (I assume Gerrit needs that).
> How come that can
> be an impediment to move forward way of this awkward way of reviewing
> patches through email?
It's not awkward, it's the most sensible way.
You just replied to my mail the same way I would reply to a patch.
> Switching to Gerrit would mean everyone would
> be using the same tool instead of anyone using its own email client
> (gmail, mutt, thunderbird, whatever...)
Yes, that's bad.
> and having to figure out git
> format-patch, git send-email (--reply-to where?).
No need to figure anything.
% git config sendemail.to git@vger.kernel.org
% git send-email @{upstream}..
Done.
> There are a lot of issues of having to use email for reviewing patches
> that I think Gerrit is a superior alternative.
There are no issues. It works for Linux, qemu, libav, ffmpeg, git, and
many other projects.
> And many people are arguing for it!
Nope, they are not.
--
Felipe Contreras
^ permalink raw reply
* git log to use .mailmap by default?
From: Jason Timrod @ 2012-11-11 12:13 UTC (permalink / raw)
To: git@vger.kernel.org
Hi,
I note that when defining a .mailmap file, that it's honoured by git-shotlog(1) by default, but for git-log(1) I have to define an entirely new --pretty= formatting option to use it.
Why is this? Why doesn't git-log honour this by default like git-shortlog does?
Would there be a way of making .mailmap be the default without needing a pretty option each time to redefine the default?
TIA!
Jason
^ permalink raw reply
* Re: Reviews on mailing-list
From: Nguyen Thai Ngoc Duy @ 2012-11-11 12:02 UTC (permalink / raw)
To: suvayu ali
Cc: Thiago Farina, Felipe Contreras, Deniz Türkoglu,
Git mailing list, Junio C Hamano, Shawn Pearce
In-Reply-To: <CAMXnza0xcH0M53BEaEyvEnShz5fGLjOtgxmTC9YMGtBsR8ratw@mail.gmail.com>
On Sun, Nov 11, 2012 at 6:11 PM, suvayu ali <fatkasuvayu+linux@gmail.com> wrote:
> I'm just a user, I found this discussion intriguing and was wondering if
> any of you have heard of patchwork server[1]. It is a patch aggregator
> for mailing lists and provides a convenient bug tracker like web
> interface without getting in the way of the workflow of reviewing
> patches on the mailing list. If you are interested the Org mode
> community (an Emacs library) uses it. You can take a look here:
>
> <http://patchwork.newartisans.com/project/org-mode/list/>
>
> I just thought this might be a nice middle ground for people.
It's been brought up several times [1] before. And Shawn wanted to do
something about this too [2]. I don't monitor gerrit so I don't know
if it has become true.
[1] http://search.gmane.org/search.php?group=gmane.comp.version-control.git&query=patchwork
[2] http://thread.gmane.org/gmane.comp.version-control.git/102887/focus=102901
--
Duy
^ permalink raw reply
* Re: Test failures in contrib/remote-helpers
From: Felipe Contreras @ 2012-11-11 12:00 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <CALkWK0mU5O3Rqznkx-qn8VLFEgsMzOba1i8onSvf8X3FBeTs6g@mail.gmail.com>
Hi,
On Sun, Nov 11, 2012 at 11:32 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> I'm experiencing test failures in contrib/remote-helpers.
Which are your versions of hg, and bzr?
--
Felipe Contreras
^ permalink raw reply
* [PATCH] Documentation/log: fix description of format.pretty
From: Ramkumar Ramachandra @ 2012-11-11 11:27 UTC (permalink / raw)
To: Git List; +Cc: Jonathan Nieder
59893a88 (Documentation/log: add a CONFIGURATION section, 2010-05-08)
mentioned that `format.pretty` is the default for the `--format`
option. Such an option never existed, and the author meant
`--pretty`. Make this correction.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
Documentation/git-log.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 585dac4..4b07ad4 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -148,7 +148,7 @@ See linkgit:git-config[1] for core variables and
linkgit:git-
for settings related to diff generation.
format.pretty::
- Default for the `--format` option. (See "PRETTY FORMATS" above.)
+ Default for the `--pretty` option. (See "PRETTY FORMATS" above.)
Defaults to "medium".
i18n.logOutputEncoding::
--
1.7.12.1.428.g652398a.dirty
^ permalink raw reply related
* Re: [PATCH] custom log formats for "diff --submodule=log"
From: Ramkumar Ramachandra @ 2012-11-11 11:26 UTC (permalink / raw)
To: Jeff King; +Cc: git, Jeffrey S. Haemer
In-Reply-To: <20121108202940.GA7982@sigill.intra.peff.net>
Hi Peff,
Jeff King wrote:
> An off-list discussion made me wonder if something like this would be
> useful:
>
> git log -p --submodule=log:' %m %an <%ae>: %s'
>
> where the format could be whatever you find useful.
Interesting. Don't you mean `git diff` in place of `git log -p`
though? I don't think `git log --submodule` does anything differently
from `git log`. Should this respect format.pretty? Does it?
Ram
^ permalink raw reply
* Re: Removing unreachable objects in the presence of broken links?
From: Geert Uytterhoeven @ 2012-11-11 11:15 UTC (permalink / raw)
To: Andreas Schwab; +Cc: git
In-Reply-To: <CAMuHMdU5ZNFs-_TeUE4ntzCCOp85DSOyWMrjJ=yV76MSmjfxDQ@mail.gmail.com>
On Mon, Oct 29, 2012 at 8:56 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Sun, Oct 28, 2012 at 10:34 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>>
>>> Is there a way to force removing unreachable objects in the presence of broken
>>> links?
>>
>> Does it help to forcibly expire the reflogs?
>
> You mean "git reflog expire --all --expire=0"?
>
> After that the reflog is empty, but "git gc" still fails.
Although "git stash list" didn't show anything, .git/refs/stash still contained
one hash.
After running "git stash clear", "git gc" succeeded, and the object pointed to
by .git/refs/stash before was gone.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Reviews on mailing-list
From: suvayu ali @ 2012-11-11 11:11 UTC (permalink / raw)
To: Thiago Farina
Cc: Felipe Contreras, Deniz Türkoglu, Git mailing list,
Junio C Hamano, Shawn Pearce
In-Reply-To: <CACnwZYekU0CYnqQT8L2siJbUsn=T9qowgth94TWc8KN472Ziag@mail.gmail.com>
Hi,
On Sun, Nov 11, 2012 at 2:13 AM, Thiago Farina <tfransosi@gmail.com> wrote:
> On Sat, Nov 10, 2012 at 9:40 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Sun, Nov 11, 2012 at 12:19 AM, Deniz Türkoglu <deniz@spotify.com> wrote:
>>
>>> This is my first mail to the git mailing list. I have been following
>>> the list for some time now and I would like to suggest moving the
>>> reviews out of the mailing list, for example to a gerrit instance, I
>>> believe it would improve the commits and the mailing list. I have a
>>> filter on 'PATCH', but I feel I miss some of the discussion, and
>>> things that I would be interested in.
>>>
>>> I have spoken to Shawn Pearce (gerrit project lead, google) and he
>>> said he is OK with hosting the gerrit instance.
>>>
>>> I would like to hear your thoughts on this.
>>
>> Personally I think reviews on the mailing list is far superior than
>> any other review methods. I've even blogged about it and all the
>> reasons[1]. Gerrit is better than bugzilla, but it still requires a
>> web browser, and logging in.
>>
> Requiring a web browser is a huge requirement, ham?? How come that can
> be an impediment to move forward way of this awkward way of reviewing
> patches through email? Switching to Gerrit would mean everyone would
> be using the same tool instead of anyone using its own email client
> (gmail, mutt, thunderbird, whatever...) and having to figure out git
> format-patch, git send-email (--reply-to where?).
>
> There are a lot of issues of having to use email for reviewing patches
> that I think Gerrit is a superior alternative.
>
> And many people are arguing for it!
>
> Let's move on...
I'm just a user, I found this discussion intriguing and was wondering if
any of you have heard of patchwork server[1]. It is a patch aggregator
for mailing lists and provides a convenient bug tracker like web
interface without getting in the way of the workflow of reviewing
patches on the mailing list. If you are interested the Org mode
community (an Emacs library) uses it. You can take a look here:
<http://patchwork.newartisans.com/project/org-mode/list/>
I just thought this might be a nice middle ground for people.
Cheers,
Footnotes:
[1] <http://jk.ozlabs.org/projects/patchwork/>
--
Suvayu
Open source is the future. It sets us free.
^ permalink raw reply
* Re: git-status: Use "-sb" options by default?
From: Ramkumar Ramachandra @ 2012-11-11 10:50 UTC (permalink / raw)
To: Jason Timrod; +Cc: git@vger.kernel.org
In-Reply-To: <1352545457.32390.YahooMailNeo@web160304.mail.bf1.yahoo.com>
Jason Timrod wrote:
> I'm looking for a way to make the "-sb" options to git-status the default somehow.
I've aliased `git status` to `git status -sb` too, and I think it's a
very sensible default; who wants to see
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
over and over again?
Maybe a status.shortWithBranch is in order? However, I don't know if
we can have one configuration option that turns on both `-s` and `-b`.
Ram
^ permalink raw reply
* Re: [PATCH 14/13] test-wildmatch: fix tests that fail on Windows due to path mangling
From: Junio C Hamano @ 2012-11-11 10:47 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jeff King, Johannes Sixt
In-Reply-To: <1352628837-5784-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Patterns beginning with a slash are converted to Windows paths before
> test-wildmatch gets to see them. Avoid this case by always writing
> XXX/abc instead of /abc. The leading XXX will be removed by
> test-wildmatch itself before processing.
>
> Any patterns beginning with a forward slash is rejected by
> test-wildmatch to avoid the same fault in future.
The title taken together with the above explanation makes it sound
as if wildmatch code does not work with the pattern /foo on Windows
at all and to avoid the issue (instead of fixing the breakage) this
patch removes such tests.
But I suspect that is not what is going on. Perhaps the title of the
change is more like "test-wildmatch: avoid Windows path mangling"
and explain with "On Windows, any command line argument that begins
with a slash is mangled as if it were a full pathname. This causes
patterns beginning with a slash not to be passed to test-wildmatch
correctly" or something?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox