* [PATCH 16/19] Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs
From: Sverre Rabbelier @ 2009-10-29 18:01 UTC (permalink / raw)
To: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
Cc: Johan Herland
In-Reply-To: <1256839287-19016-1-git-send-email-srabbelier@gmail.com>
From: Johan Herland <johan@herland.net>
Junio discovered that the installed git-remote-cvs executable is unable
to find the installed git_remote_cvs Python package. This is due to the
'instlibdir' target of git_remote_cvs/Makefile being invoked with
insufficient arguments (prefix and DESTDIR). This patch fixes that.
Signed-off-by: Johan Herland <johan@herland.net>
---
Unchanged.
Makefile | 2 +-
git_remote_cvs/Makefile | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index a63f44d..9fb2747 100644
--- a/Makefile
+++ b/Makefile
@@ -1525,7 +1525,7 @@ endif # NO_PERL
ifndef NO_PYTHON
$(patsubst %.py,%,$(SCRIPT_PYTHON)): % : %.py
$(QUIET_GEN)$(RM) $@ $@+ && \
- INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C git_remote_cvs -s --no-print-directory instlibdir` && \
+ INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C git_remote_cvs -s --no-print-directory prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' instlibdir` && \
sed -e '1{' \
-e ' s|#!.*python|#!$(PYTHON_PATH_SQ)|' \
-e '}' \
diff --git a/git_remote_cvs/Makefile b/git_remote_cvs/Makefile
index 061c247..0d9eb31 100644
--- a/git_remote_cvs/Makefile
+++ b/git_remote_cvs/Makefile
@@ -28,7 +28,7 @@ install: $(pysetupfile)
$(PYTHON_PATH) $(pysetupfile) install --prefix $(DESTDIR_SQ)$(prefix)
instlibdir: $(pysetupfile)
- @echo "$(prefix)/$(PYLIBDIR)"
+ @echo "$(DESTDIR_SQ)$(prefix)/$(PYLIBDIR)"
clean:
$(QUIET)$(PYTHON_PATH) $(pysetupfile) $(QUIETSETUP) clean -a
--
1.6.5.2.291.gf76a3
^ permalink raw reply related
* [PATCH 17/19] More fixes to the git-remote-cvs installation procedure
From: Sverre Rabbelier @ 2009-10-29 18:01 UTC (permalink / raw)
To: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
Cc: Johan Herland
In-Reply-To: <1256839287-19016-1-git-send-email-srabbelier@gmail.com>
From: Johan Herland <johan@herland.net>
- Makefile: Make sure git-remote-cvs is rebuilt when 'prefix' changes
(by adding a dependency on GIT-CFLAGS). This prevents a regular 'make'
followed by a 'make prefix=/somewhere/else install' from installing a
non-working git-remote-cvs.
- Makefile: When mangling git-remote-cvs to add the git_remote_cvs install
location to the Python search path, _replace_ the initial 'current dir'
entry in sys.path (instead of merely prepending the install location).
Hence, if the git_remote_cvs package is not installed at the correct
location (and also not present in any of Python's default package dirs),
then git-remote-cvs will fail loudly instead of silently falling back on
the git_remote_cvs subdir in git.git.
- Allow for the git_remote_cvs install path to be overridden by the
$GITPYTHONLIB environment variable.
- t/test-lib.sh: Set $GITPYTHONLIB (unless $GIT_TEST_INSTALLED is enabled)
so that we test the currently built version of git_remote_cvs (the one
that is built in git_remote_cvs/build/lib) instead of a previously
installed version.
- Another minor check and a line length fix.
Found-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johan Herland <johan@herland.net>
---
Unchanged.
Makefile | 11 +++++++++--
t/test-lib.sh | 9 +++++++++
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 9fb2747..6d37399 100644
--- a/Makefile
+++ b/Makefile
@@ -1523,13 +1523,20 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)) git-instaweb: % : unimplemented.sh
endif # NO_PERL
ifndef NO_PYTHON
+$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS
$(patsubst %.py,%,$(SCRIPT_PYTHON)): % : %.py
$(QUIET_GEN)$(RM) $@ $@+ && \
- INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C git_remote_cvs -s --no-print-directory prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' instlibdir` && \
+ INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C git_remote_cvs -s \
+ --no-print-directory prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' \
+ instlibdir` && \
sed -e '1{' \
-e ' s|#!.*python|#!$(PYTHON_PATH_SQ)|' \
-e '}' \
- -e 's|^import sys.*|&; sys.path.insert(0, "@@INSTLIBDIR@@")|' \
+ -e 's|^import sys.*|&; \\\
+ import os; \\\
+ sys.path[0] = os.environ.has_key("GITPYTHONLIB") and \\\
+ os.environ["GITPYTHONLIB"] or \\\
+ "@@INSTLIBDIR@@"|' \
-e 's|@@INSTLIBDIR@@|'"$$INSTLIBDIR"'|g' \
$@.py >$@+ && \
chmod +x $@+ && \
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 0b991db..77ad23e 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -638,6 +638,15 @@ test -d ../templates/blt || {
error "You haven't built things yet, have you?"
}
+if test -z "$GIT_TEST_INSTALLED"
+then
+ GITPYTHONLIB="$(pwd)/../git_remote_cvs/build/lib"
+ export GITPYTHONLIB
+ test -d ../git_remote_cvs/build || {
+ error "You haven't built git_remote_cvs yet, have you?"
+ }
+fi
+
if ! test -x ../test-chmtime; then
echo >&2 'You need to build test-chmtime:'
echo >&2 'Run "make test-chmtime" in the source (toplevel) directory'
--
1.6.5.2.291.gf76a3
^ permalink raw reply related
* [PATCH 18/19] Refactor git_remote_cvs to a more generic git_remote_helpers
From: Sverre Rabbelier @ 2009-10-29 18:01 UTC (permalink / raw)
To: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
Cc: Sverre Rabbelier
In-Reply-To: <1256839287-19016-1-git-send-email-srabbelier@gmail.com>
This in an effort to allow future remote helpers written in python to
re-use the non-cvs-specific code.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
This time with -M -C :).
Makefile | 8 +++---
git-remote-cvs.py | 14 +++++-----
git_remote_cvs/__init__.py | 27 --------------------
git_remote_cvs/setup.py | 17 ------------
{git_remote_cvs => git_remote_helpers}/.gitignore | 0
{git_remote_cvs => git_remote_helpers}/Makefile | 2 +-
git_remote_helpers/__init__.py | 27 ++++++++++++++++++++
.../cvs}/changeset.py | 2 +-
.../cvs}/commit_states.py | 4 +-
{git_remote_cvs => git_remote_helpers/cvs}/cvs.py | 6 ++--
.../cvs/revision_map.py | 6 ++--
.../cvs/symbol_cache.py | 4 +-
{git_remote_cvs => git_remote_helpers/git}/git.py | 4 +-
git_remote_helpers/setup.py | 17 ++++++++++++
{git_remote_cvs => git_remote_helpers}/util.py | 0
t/test-lib.sh | 4 +-
16 files changed, 71 insertions(+), 71 deletions(-)
delete mode 100644 git_remote_cvs/__init__.py
delete mode 100644 git_remote_cvs/setup.py
rename {git_remote_cvs => git_remote_helpers}/.gitignore (100%)
rename {git_remote_cvs => git_remote_helpers}/Makefile (92%)
create mode 100644 git_remote_helpers/__init__.py
create mode 100644 git_remote_helpers/cvs/__init__.py
rename {git_remote_cvs => git_remote_helpers/cvs}/changeset.py (98%)
rename {git_remote_cvs => git_remote_helpers/cvs}/commit_states.py (95%)
rename {git_remote_cvs => git_remote_helpers/cvs}/cvs.py (99%)
rename git_remote_cvs/cvs_revision_map.py => git_remote_helpers/cvs/revision_map.py (98%)
rename git_remote_cvs/cvs_symbol_cache.py => git_remote_helpers/cvs/symbol_cache.py (98%)
create mode 100644 git_remote_helpers/git/__init__.py
rename {git_remote_cvs => git_remote_helpers/git}/git.py (99%)
create mode 100644 git_remote_helpers/setup.py
rename {git_remote_cvs => git_remote_helpers}/util.py (100%)
diff --git a/Makefile b/Makefile
index 6d37399..70b8195 100644
--- a/Makefile
+++ b/Makefile
@@ -1402,7 +1402,7 @@ ifndef NO_PERL
$(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' all
endif
ifndef NO_PYTHON
- $(QUIET_SUBDIR0)git_remote_cvs $(QUIET_SUBDIR1) PYTHON_PATH='$(PYTHON_PATH_SQ)' prefix='$(prefix_SQ)' all
+ $(QUIET_SUBDIR0)git_remote_helpers $(QUIET_SUBDIR1) PYTHON_PATH='$(PYTHON_PATH_SQ)' prefix='$(prefix_SQ)' all
endif
$(QUIET_SUBDIR0)templates $(QUIET_SUBDIR1)
@@ -1526,7 +1526,7 @@ ifndef NO_PYTHON
$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS
$(patsubst %.py,%,$(SCRIPT_PYTHON)): % : %.py
$(QUIET_GEN)$(RM) $@ $@+ && \
- INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C git_remote_cvs -s \
+ INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C git_remote_helpers -s \
--no-print-directory prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' \
instlibdir` && \
sed -e '1{' \
@@ -1776,7 +1776,7 @@ ifndef NO_PERL
$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
endif
ifndef NO_PYTHON
- $(MAKE) -C git_remote_cvs prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
+ $(MAKE) -C git_remote_helpers prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
endif
ifndef NO_TCLTK
$(MAKE) -C gitk-git install
@@ -1893,7 +1893,7 @@ ifndef NO_PERL
$(MAKE) -C perl clean
endif
ifndef NO_PYTHON
- $(MAKE) -C git_remote_cvs clean
+ $(MAKE) -C git_remote_helpers clean
endif
$(MAKE) -C templates/ clean
$(MAKE) -C t/ clean
diff --git a/git-remote-cvs.py b/git-remote-cvs.py
index 94b61e7..f322f96 100755
--- a/git-remote-cvs.py
+++ b/git-remote-cvs.py
@@ -36,16 +36,16 @@ configuration details of this remote helper.
import sys
import os
-from git_remote_cvs.util import (debug, error, die, ProgressIndicator,
+from git_remote_helpers.util import (debug, error, die, ProgressIndicator,
run_command)
-from git_remote_cvs.cvs import CVSState, CVSWorkDir, fetch_revs
-from git_remote_cvs.git import (get_git_dir, parse_git_config, git_config_bool,
+from git_remote_helpers.cvs.cvs import CVSState, CVSWorkDir, fetch_revs
+from git_remote_helpers.git.git import (get_git_dir, parse_git_config, git_config_bool,
valid_git_ref, GitObjectFetcher, GitRefMap,
GitFICommit, GitFastImport, GitNotes)
-from git_remote_cvs.cvs_symbol_cache import CVSSymbolCache
-from git_remote_cvs.commit_states import CommitStates
-from git_remote_cvs.cvs_revision_map import CVSRevisionMap, CVSStateMap
-from git_remote_cvs.changeset import build_changesets_from_revs
+from git_remote_helpers.cvs.symbol_cache import CVSSymbolCache
+from git_remote_helpers.cvs.commit_states import CommitStates
+from git_remote_helpers.cvs.revision_map import CVSRevisionMap, CVSStateMap
+from git_remote_helpers.cvs.changeset import build_changesets_from_revs
class Config(object):
diff --git a/git_remote_cvs/__init__.py b/git_remote_cvs/__init__.py
deleted file mode 100644
index 4956d2d..0000000
--- a/git_remote_cvs/__init__.py
+++ /dev/null
@@ -1,27 +0,0 @@
-#!/usr/bin/env python
-
-"""Support library package for git-remote-cvs.
-
-git-remote-cvs is a Git remote helper command that interfaces with a
-CVS repository to provide automatic import of CVS history into a Git
-repository.
-
-This package provides the support library needed by git-remote-cvs.
-The following modules are included:
-
-- cvs - Interaction with CVS repositories
-
-- cvs_symbol_cache - Local CVS symbol cache
-
-- changeset - Collect individual CVS revisions into commits
-
-- git - Interaction with Git repositories
-
-- commit_states - Map Git commits to CVS states
-
-- cvs_revision_map - Map CVS revisions to various metainformation
-
-- util - General utility functionality use by the other modules in
- this package, and also used directly by git-remote-cvs.
-
-"""
diff --git a/git_remote_cvs/setup.py b/git_remote_cvs/setup.py
deleted file mode 100644
index 21f521a..0000000
--- a/git_remote_cvs/setup.py
+++ /dev/null
@@ -1,17 +0,0 @@
-#!/usr/bin/env python
-
-"""Distutils build/install script for the git_remote_cvs package."""
-
-from distutils.core import setup
-
-setup(
- name = 'git_remote_cvs',
- version = '0.1.0',
- description = 'Git remote helper program for CVS repositories',
- license = 'GPLv2',
- author = 'The Git Community',
- author_email = 'git@vger.kernel.org',
- url = 'http://www.git-scm.com/',
- package_dir = {'git_remote_cvs': ''},
- packages = ['git_remote_cvs'],
-)
diff --git a/git_remote_cvs/.gitignore b/git_remote_helpers/.gitignore
similarity index 100%
rename from git_remote_cvs/.gitignore
rename to git_remote_helpers/.gitignore
diff --git a/git_remote_cvs/Makefile b/git_remote_helpers/Makefile
similarity index 92%
rename from git_remote_cvs/Makefile
rename to git_remote_helpers/Makefile
index 0d9eb31..c62dfd0 100644
--- a/git_remote_cvs/Makefile
+++ b/git_remote_helpers/Makefile
@@ -1,5 +1,5 @@
#
-# Makefile for the git_remote_cvs python support modules
+# Makefile for the git_remote_helpers python support modules
#
pysetupfile:=setup.py
diff --git a/git_remote_helpers/__init__.py b/git_remote_helpers/__init__.py
new file mode 100644
index 0000000..38c7b5f
--- /dev/null
+++ b/git_remote_helpers/__init__.py
@@ -0,0 +1,27 @@
+#!/usr/bin/env python
+
+"""Support library package for git remote helpers.
+
+Git remote helpers are helper commands that interfaces with a non-git
+repository to provide automatic import of non-git history into a Git
+repository.
+
+This package provides the support library needed by these helpers..
+The following modules are included:
+
+- cvs/cvs - Interaction with CVS repositories
+
+- cvs/symbol_cache - Local CVS symbol cache
+
+- cvs/changeset - Collect individual CVS revisions into commits
+
+- cvs/commit_states - Map Git commits to CVS states
+
+- cvs/revision_map - Map CVS revisions to various metainformation
+
+- git/git - Interaction with Git repositories
+
+- util - General utility functionality use by the other modules in
+ this package, and also used directly by git-remote-cvs.
+
+"""
diff --git a/git_remote_helpers/cvs/__init__.py b/git_remote_helpers/cvs/__init__.py
new file mode 100644
index 0000000..e69de29
diff --git a/git_remote_cvs/changeset.py b/git_remote_helpers/cvs/changeset.py
similarity index 98%
rename from git_remote_cvs/changeset.py
rename to git_remote_helpers/cvs/changeset.py
index 9eea9d2..4865c37 100644
--- a/git_remote_cvs/changeset.py
+++ b/git_remote_helpers/cvs/changeset.py
@@ -11,7 +11,7 @@ module tries to reconstruct this notion of related revisions.
"""
-from git_remote_cvs.util import debug, error, die
+from git_remote_helpers.util import debug, error, die
class Changeset(object):
diff --git a/git_remote_cvs/commit_states.py b/git_remote_helpers/cvs/commit_states.py
similarity index 95%
rename from git_remote_cvs/commit_states.py
rename to git_remote_helpers/cvs/commit_states.py
index 2e0af6c..a796bb1 100644
--- a/git_remote_cvs/commit_states.py
+++ b/git_remote_helpers/cvs/commit_states.py
@@ -2,8 +2,8 @@
"""Code for relating Git commits to corresponding CVSState objects."""
-from git_remote_cvs.util import debug, error, die
-from git_remote_cvs.cvs import CVSState
+from git_remote_helpers.util import debug, error, die
+from git_remote_helpers.cvs.cvs import CVSState
class CommitStates(object):
diff --git a/git_remote_cvs/cvs.py b/git_remote_helpers/cvs/cvs.py
similarity index 99%
rename from git_remote_cvs/cvs.py
rename to git_remote_helpers/cvs/cvs.py
index f870ae0..a1a02be 100644
--- a/git_remote_cvs/cvs.py
+++ b/git_remote_helpers/cvs/cvs.py
@@ -17,9 +17,9 @@ import time
from calendar import timegm
import unittest
-from git_remote_cvs.util import (debug, error, die, ProgressIndicator,
- start_command, run_command,
- file_reader_method, file_writer_method)
+from git_remote_helpers.util import (debug, error, die, ProgressIndicator,
+ start_command, run_command,
+ file_reader_method, file_writer_method)
class CVSNum(object):
diff --git a/git_remote_cvs/cvs_revision_map.py b/git_remote_helpers/cvs/revision_map.py
similarity index 98%
rename from git_remote_cvs/cvs_revision_map.py
rename to git_remote_helpers/cvs/revision_map.py
index 0e65ba6..b7b17bc 100644
--- a/git_remote_cvs/cvs_revision_map.py
+++ b/git_remote_helpers/cvs/revision_map.py
@@ -18,9 +18,9 @@ CVSStateMap - provides a mapping from CVS states to corresponding
import os
-from git_remote_cvs.util import debug, error, die, file_reader_method
-from git_remote_cvs.cvs import CVSNum, CVSDate
-from git_remote_cvs.git import GitFICommit
+from git_remote_helpers.util import debug, error, die, file_reader_method
+from git_remote_helpers.cvs.cvs import CVSNum, CVSDate
+from git_remote_helpers.git.git import GitFICommit
class _CVSPathInfo(object):
diff --git a/git_remote_cvs/cvs_symbol_cache.py b/git_remote_helpers/cvs/symbol_cache.py
similarity index 98%
rename from git_remote_cvs/cvs_symbol_cache.py
rename to git_remote_helpers/cvs/symbol_cache.py
index cc8d88b..6bd1715 100644
--- a/git_remote_cvs/cvs_symbol_cache.py
+++ b/git_remote_helpers/cvs/symbol_cache.py
@@ -23,8 +23,8 @@ synchronizing _all_ CVS symbols in one operation (by executing
import sys
import os
-from git_remote_cvs.util import debug, error, die, ProgressIndicator
-from git_remote_cvs.cvs import CVSNum, CVSState, CVSLogParser
+from git_remote_helpers.util import debug, error, die, ProgressIndicator
+from git_remote_helpers.cvs.cvs import CVSNum, CVSState, CVSLogParser
class CVSSymbolStateLister(CVSLogParser):
diff --git a/git_remote_helpers/git/__init__.py b/git_remote_helpers/git/__init__.py
new file mode 100644
index 0000000..e69de29
diff --git a/git_remote_cvs/git.py b/git_remote_helpers/git/git.py
similarity index 99%
rename from git_remote_cvs/git.py
rename to git_remote_helpers/git/git.py
index cf037e3..8e1bc77 100644
--- a/git_remote_cvs/git.py
+++ b/git_remote_helpers/git/git.py
@@ -12,8 +12,8 @@ from binascii import hexlify
from cStringIO import StringIO
import unittest
-from git_remote_cvs.util import debug, error, die, start_command, run_command
-from git_remote_cvs.cvs import CVSDate
+from git_remote_helpers.util import debug, error, die, start_command, run_command
+from git_remote_helpers.cvs.cvs import CVSDate
def get_git_dir ():
diff --git a/git_remote_helpers/setup.py b/git_remote_helpers/setup.py
new file mode 100644
index 0000000..327f0ff
--- /dev/null
+++ b/git_remote_helpers/setup.py
@@ -0,0 +1,17 @@
+#!/usr/bin/env python
+
+"""Distutils build/install script for the git_remote_helpers package."""
+
+from distutils.core import setup
+
+setup(
+ name = 'git_remote_helpers',
+ version = '0.1.0',
+ description = 'Git remote helper program for non-git repositories',
+ license = 'GPLv2',
+ author = 'The Git Community',
+ author_email = 'git@vger.kernel.org',
+ url = 'http://www.git-scm.com/',
+ package_dir = {'git_remote_helpers': ''},
+ packages = ['git_remote_helpers', 'git_remote_helpers.git', 'git_remote_helpers.cvs'],
+)
diff --git a/git_remote_cvs/util.py b/git_remote_helpers/util.py
similarity index 100%
rename from git_remote_cvs/util.py
rename to git_remote_helpers/util.py
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 77ad23e..c7530aa 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -640,9 +640,9 @@ test -d ../templates/blt || {
if test -z "$GIT_TEST_INSTALLED"
then
- GITPYTHONLIB="$(pwd)/../git_remote_cvs/build/lib"
+ GITPYTHONLIB="$(pwd)/../git_remote_helpers/build/lib"
export GITPYTHONLIB
- test -d ../git_remote_cvs/build || {
+ test -d ../git_remote_helpers/build || {
error "You haven't built git_remote_cvs yet, have you?"
}
fi
--
1.6.5.2.291.gf76a3
^ permalink raw reply related
* [PATCH 19/19] .gitignore: add git-remote-cvs
From: Sverre Rabbelier @ 2009-10-29 18:01 UTC (permalink / raw)
To: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
Cc: Sverre Rabbelier
In-Reply-To: <1256839287-19016-1-git-send-email-srabbelier@gmail.com>
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 51a37b1..461f6ee 100644
--- a/.gitignore
+++ b/.gitignore
@@ -105,6 +105,7 @@ git-reflog
git-relink
git-remote
git-remote-curl
+git-remote-cvs
git-repack
git-replace
git-repo-config
--
1.6.5.2.291.gf76a3
^ permalink raw reply related
* Re: [PATCH 19/19] .gitignore: add git-remote-cvs
From: Shawn O. Pearce @ 2009-10-29 18:05 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
In-Reply-To: <1256839287-19016-20-git-send-email-srabbelier@gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> wrote:
> diff --git a/.gitignore b/.gitignore
> index 51a37b1..461f6ee 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -105,6 +105,7 @@ git-reflog
> git-relink
> git-remote
> git-remote-curl
> +git-remote-cvs
> git-repack
> git-replace
> git-repo-config
Uh, squash to "[PATCH 14/19] git-remote-cvs: Remote help..." ?
--
Shawn.
^ permalink raw reply
* Re: [PATCH 19/19] .gitignore: add git-remote-cvs
From: Sverre Rabbelier @ 2009-10-29 18:08 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
In-Reply-To: <20091029180538.GC10505@spearce.org>
Heya,
On Thu, Oct 29, 2009 at 11:05, Shawn O. Pearce <spearce@spearce.org> wrote:
> Uh, squash to "[PATCH 14/19] git-remote-cvs: Remote help..." ?
Durr, my bad, done locally, not sending another version yet though :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 0/4] Cygwin MSVC patches
From: Ramsay Jones @ 2009-10-28 22:21 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, GIT Mailing-list, mstormo
In-Reply-To: <4AE7EB06.10305@viscovery.net>
Johannes Sixt wrote:
> Ramsay Jones schrieb:
>> With these patches, the msvc build on cygwin seems to be working fine.
>
> What is "the msvc build on cygwin"?
The same as the msvc build on msys-MinGW, but replace msys-MinGW
with Cygwin ;-)
> Is it "git built with msvc, then run in cygwin"?
Yes, but... *in theory* the cygwin msvc-built binaries could be transferred
to an msys system and they should work (exactly as the msvc build on msys).
Since I don't have an msys installation, I can't test that... so I won't
guarantee it will work!
Any git needs a (bash-like) shell, perl, Tcl/Tk, ... etc.
Note the difference in the cygcheck output on the (cygwin) msvc-built git:
$ cygcheck ./git.exe
.\git.exe
C:\WINDOWS\system32\ADVAPI32.dll
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\RPCRT4.dll
C:\WINDOWS\system32\Secur32.dll
C:\WINDOWS\system32\SHELL32.dll
C:\WINDOWS\system32\GDI32.dll
C:\WINDOWS\system32\USER32.dll
C:\WINDOWS\system32\msvcrt.dll
C:\WINDOWS\system32\SHLWAPI.dll
C:\WINDOWS\system32\WS2_32.dll
C:\WINDOWS\system32\WS2HELP.dll
C:\WINDOWS\system32\zlib1.dll
$
rather than the cygwin git:
$ cygcheck ./git.exe
.\git.exe
C:\cygwin\bin\cygcrypto-0.9.8.dll
C:\cygwin\bin\cygwin1.dll
C:\WINDOWS\system32\ADVAPI32.DLL
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\RPCRT4.dll
C:\WINDOWS\system32\Secur32.dll
C:\cygwin\bin\cygiconv-2.dll
C:\cygwin\bin\cygz.dll
$
[Actually, one difference between the msys and cygwin msvc builds
is that I have dynamically linked to the zlib1.dll rather than
using the static library from the msvcgit.git dependencies repo.]
ATB,
Ramsay Jones
^ permalink raw reply
* Projects within projects
From: Nick Colgan @ 2009-10-29 18:40 UTC (permalink / raw)
To: git
I'm currently working on a project made up of parts that could each be
considered a project in itself. I plan on using redmine or trac to
manage the project. Now I'm trying to figure out how to manage the
repo(s) for the project.
These are the current options I have in mind:
1. Create a separate repository for each sub-project and manage each
separately in redmine (separate bug tracker, wiki, etc.)
2. Create a single repository with a subdirectory for each sub-project.
3. Use git submodules or subversion externals to combine options 1 and 2
by creating a separate repo for each sub-project, then creating a master
repo with subdirectory for each sub-project that imports from their
respective repositories.
What's the best way to handle this situation? Are git submodules and/or
svn externals sufficiently capable of dealing with this?
Thanks,
nic.
^ permalink raw reply
* Re: [PATCH 7/7] Factor ref updating out of fetch_with_import
From: Daniel Barkalow @ 2009-10-29 18:43 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Shawn O. Pearce, Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <fabb9a1e0910291039u3c9d7eb6qe36e25ea76cdddc9@mail.gmail.com>
On Thu, 29 Oct 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Thu, Oct 29, 2009 at 10:22, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > (a) if HEAD is determined to be a symref, and we care about HEAD, we care
> > about whatever HEAD is a symref to; wanted_peer_refs() shouldn't be
> > filtering such things out.
>
> It seems that wanted_peer_refs filters out HEAD no matter what though?
It probably shouldn't. Actually, I bet Nico's clone will get extremely
confused if the remote's HEAD isn't the same as any of its branches. I'll
try to take a look tonight.
> > (b) we don't want to make a whole bunch of copies of the ref list to avoid
> > updating the mutable ref list that we will look for updated values in; the
> > merge of my series with Nico's should replace my copy_ref_list with his
> > wanted_peer_refs, not include the copy afterwards. Correcting this should
> > lead to the value that matters in the list that will be used having been
> > updated directly by transport_fetch_refs().
>
> This I can and will fix. Patch-bomb incoming.
I'll look over it later, thanks.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 7/7] Factor ref updating out of fetch_with_import
From: Sverre Rabbelier @ 2009-10-29 18:47 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Shawn O. Pearce, Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <alpine.LNX.2.00.0910291435180.14365@iabervon.org>
Heya,
On Thu, Oct 29, 2009 at 11:43, Daniel Barkalow <barkalow@iabervon.org> wrote:
> It probably shouldn't. Actually, I bet Nico's clone will get extremely
> confused if the remote's HEAD isn't the same as any of its branches. I'll
> try to take a look tonight.
>
> I'll look over it later, thanks.
Thanks!
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Projects within projects
From: Avery Pennarun @ 2009-10-29 18:56 UTC (permalink / raw)
To: Nick Colgan; +Cc: git
In-Reply-To: <ab1d51700910291140ncd80027j4ee9a30637d7bc40@mail.gmail.com>
On Thu, Oct 29, 2009 at 2:40 PM, Nick Colgan <nick.colgan@gmail.com> wrote:
> These are the current options I have in mind:
>
> 1. Create a separate repository for each sub-project and manage each
> separately in redmine (separate bug tracker, wiki, etc.)
>
> 2. Create a single repository with a subdirectory for each sub-project.
>
> 3. Use git submodules or subversion externals to combine options 1 and 2
> by creating a separate repo for each sub-project, then creating a master
> repo with subdirectory for each sub-project that imports from their
> respective repositories.
>
> What's the best way to handle this situation? Are git submodules and/or
> svn externals sufficiently capable of dealing with this?
Every way has tradeoffs. I'd suggest first thinking about whether
these supposedly independent projects are *really* going to be
independent or not. If they're unlikely to ever be reused - or they
won't be for a long time - #2 is by far the easiest choice.
If you choose #2 and then choose to split the repo later, you can use
git-subtree (http://github.com/apenwarr/git-subtree) to split it
easily, so there's little sacrifice in using #2 at first and changing
your mind later.
If you choose #3, that's exactly that git-submodule and svn:externals
are for, and it seems to work okay for a lot of people. It's more
work though, since you have to be careful to isolate commits between
one project and another, etc. Personally I prefer to use git-subtree
for this too, but it's a matter of preference.
Have fun,
Avery
^ permalink raw reply
* Re: Projects within projects
From: Bill Lear @ 2009-10-29 19:33 UTC (permalink / raw)
To: Nick Colgan; +Cc: git
In-Reply-To: <ab1d51700910291140ncd80027j4ee9a30637d7bc40@mail.gmail.com>
On Thursday, October 29, 2009 at 14:40:36 (-0400) Nick Colgan writes:
>I'm currently working on a project made up of parts that could each be
>considered a project in itself. I plan on using redmine or trac to
>manage the project. Now I'm trying to figure out how to manage the
>repo(s) for the project.
>
>These are the current options I have in mind:
>
>1. Create a separate repository for each sub-project and manage each
>separately in redmine (separate bug tracker, wiki, etc.)
>
>2. Create a single repository with a subdirectory for each sub-project.
>
>3. Use git submodules or subversion externals to combine options 1 and 2
>by creating a separate repo for each sub-project, then creating a master
>repo with subdirectory for each sub-project that imports from their
>respective repositories.
>
>What's the best way to handle this situation? Are git submodules and/or
>svn externals sufficiently capable of dealing with this?
Let me give you an example of #3. I write a fair amount in C++ and
have written a reasonably sophisticated makefile system to allow me to
create a new directory in a project, put files in it, link in a master
makefile, cd into the directory and type 'make' and have things build
without me having to edit the makefile --- I don't want to write
makefile rules, etc., I want to write C++ (fill in the blank here).
It basically relies on naming conventions, but it suits me perfectly.
If I name a file test_*.cc or t_*.cc, or tc_*.cc, it is a unit test,
if I name it m_*.cc, or main_*.cc, it is a main program. Library
inter-dependencies are easy to set up in a central way, blah blah blah
--- the details are not terribly important.
In any case, I created a new project to work on some "real-time"
financial trading algorithms. I did this by creating a new repository
into which I added a src directory, under which were several other
directories of source code. At the top level of the new repo, I added
a git submodule 'mk' that contains my makefile system. I then linked
the master makefile to my source directory makefile and was off
compiling easily.
In this case, I do absolutely reuse my makefile system across multiple
projects. It is 100% orthogonal, and I have so far found it to be
very useful to use git submodules.
I imagine also if you are building software that is 100% orthogonal
that you would like to reuse in many projects, git submobules is the
way to go.
I read the Git Submodule Tutorial on the Git Wiki and found myself
able to use submodules very easily after that.
bill
^ permalink raw reply
* Tracking a remote branch in git
From: Sips @ 2009-10-29 19:45 UTC (permalink / raw)
To: git
Hello everyone.
My git setup is as follows:
One local repository residing at D:\Dev\ProjectName
One remote repository residing at W:\ProjectName
W is actually a removable disk.
Now, both repositories are connected through remotes. For example, git
remote -v in the local repository gives:
storengo W:\ProjectName (fetch)
storengo W:\ProjectName (push)
The same command in the remote repository gives:
origin D:\Dev\ProjectName (fetch)
origin D:\Dev\ProjectName (push)
Obviously, when I am in the master branch, I can synchronize repositories
between each other through git push and git pull.
Then I created a branch in the repository on the removable drive W and named
it newfeature. The question is: How can I work with this branch on the local
repository as well? I mean, I need the same 'relationship' between branches
as in case of the master branch.
I tried the following command on the local repository (which was checked out
to the master branch at that time):
git branch --track newfeature storengo/newfeature,
but received an error fatal: Not a valid object name: 'storengo/newfeature'.
With this command I was hoping to create a local branch which would be
'connected' to the same remote branch. As I've said, no luck there.
Strangely, the following command works without errors:
git branch --track newfeature storengo/master.
I mean, I am able to track the master branch from the remote repository. Why
can't I track some other branch as well? Any ideas what I'm doing wrong?
Thanks,
Kirill
--
View this message in context: http://www.nabble.com/Tracking-a-remote-branch-in-git-tp26119537p26119537.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH/RFC 2/2] Provide a build time default-editor setting
From: Junio C Hamano @ 2009-10-29 20:40 UTC (permalink / raw)
To: Johannes Sixt
Cc: David Roundy, Jonathan Nieder, Junio C Hamano, Ben Walton,
GIT List
In-Reply-To: <4AE98175.504@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> David Roundy schrieb:
>> Any chance this will be exported as plumbing? I know it's pretty
>> high-level, but it'd be handy to have be able to write `git editor
>> $FILENAME` and just have it do the right thing. This would also mean
>> that the perl scripts below could be simplified.
>
> Something like below? Possible usage in shell scripts:
>
> editor=$(git var GIT_EDITOR)
> "$editor" "$filename"
I think we support GIT_EDITOR that is command path plus its initial
command line arguments, so you do not want dq around $editor, right?
^ permalink raw reply
* Re: [PATCH/RFC 2/2] Provide a build time default-editor setting
From: Junio C Hamano @ 2009-10-29 20:43 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Ben Walton, GIT List
In-Reply-To: <20091029075021.GC15403@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Provide a DEFAULT_EDITOR knob to allow the fallback editor (to
> use instead of vi if VISUAL, EDITOR, and GIT_EDITOR are unset) to
> be set at build time according to a system’s policy. For
> example, on Debian systems, the default editor should be the
> 'editor' command.
I think we allow things like
GIT_EDITOR='"/c/my program/vi" --i-like-color --config=$HOME/.myvicfg'
and the eval construct in git-sh-setup.sh is about supporting that kind of
insanity^Wflexibility.
My "how about" patch on DEFAULT_PAGER might be minimally safe with
make DEFAULT_PAGER="/c/my program/less"
but if you are going to do this for real, you would need to use proper
quoting in the Makefile (look for _SQ for hints).
Also I do not think it allows this at all:
make DEFAULT_PAGER='"/c/my program/less" --i-like-color'
It probably is Ok to force the "default" one to be just the path to the
command (i.e. not part of command line), but I thought this would be worth
pointing out.
> This change makes t7005-editor into a mess. Any ideas for fixing
> this?
I think the introduction of DEFAULT_EDITOR makes it unfixable; your
DEFAULT_EDITOR may be set to '/usr/bin/vi' not 'vi'.
Just detect DEFAULT_EDITOR being not the default 'vi' and abort/skip the
entire test, perhaps?
^ permalink raw reply
* Re: [RFC PATCH v4 03/26] pkt-line: Make packet_read_line easier to debug
From: Junio C Hamano @ 2009-10-29 20:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20091029151152.GX10505@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>> > diff --git a/pkt-line.c b/pkt-line.c
>> > index bd603f8..893dd3c 100644
>> > --- a/pkt-line.c
>> > +++ b/pkt-line.c
>> > @@ -124,12 +124,14 @@ static int packet_length(const char *linelen)
>> > int packet_read_line(int fd, char *buffer, unsigned size)
>> > {
>> > int len;
>> > - char linelen[4];
>> > + char linelen[5];
>> >
>> > safe_read(fd, linelen, 4);
>> > len = packet_length(linelen);
>> > - if (len < 0)
>> > - die("protocol error: bad line length character");
>> > + if (len < 0) {
>> > + linelen[4] = '\0';
>> > + die("protocol error: bad line length character: %s", linelen);
>> > + }
>>
>> Since this is not called recursively, you can make linelen[] static
>
> Sure. But it wasn't static before. It was stack allocated. Its a
> 5 byte stack allocation. Its not a lot of data to push onto the
> stack, why does it suddenly matter that we make it static and charge
> everyone for its memory instead of just those who really need it?
>
>> and do
>> without the NUL assignment; safe_read() won't read beyond 4 bytes anyway.
>
> The NUL assignment isn't about safe_read(), its about making the
> block of 4 bytes read a proper C-style string so we can safely pass
> it down into the snprintf that is within die().
I knew and understood all of what you just said. static linelen[] is not
about stack allocation. It's about letting the compiler initialize it to
five NULs so that you do not have to assign NUL to its fifth place before
you die. This removes one added line from your patch.
^ permalink raw reply
* Re: [RFC PATCH v4 14/26] Add stateless RPC options to upload-pack, receive-pack
From: Junio C Hamano @ 2009-10-29 20:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20091029152629.GY10505@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> One approach is to use an HMAC and sign each advertised SHA-1
> during the initial --advertise-refs phase. Requesters then present
> the SHA-1 and the HAMC signature in each "want" line, and the
> --stateless-rpc phase validates the signatures to ensure they came
> from a trusted party.
>
> The major problem with this approach is the private key management.
> All mirrors of that repository need to have a common private key
> so they can generate and later verify that HMAC signature. This is
> additional complexity, for perhaps not much gain.
I am not worried so much about malicious clients getting themselves
confused. One simple alternative would be to internally recreate the
response the requestee would send if it were the first phase request upon
receiving the request for the second phase---then you take an SHA-1 hash
of it. In the second phase request have the requestor include the SHA-1
hash of what it received in the response to its first phase request, and
the requestee can make sure they match. No per-ref signing nor secret key
management is necessary, and it would let the requestor retry if you allow
the response to the second phase request to be "your request is stale, try
again".
> A different approach is to have the --stateless-rpc phase validate
> the want lines against its refs (like we do now), but if the validate
> fails (no ref exactly matches) support walking backwards through the
> last few records in the reflog, or through that ref's own history
> for a few hundred commits, to see if the want SHA-1 appears in the
> recent prior past.
>
> Obviously when walking the reflog we would need to use a time bound,
> e.g. "only examine last record if more recent than 5 minutes ago".
I think that is probably too much complexity for too little gain. I think
detecting stale request and having requestor retry would be sufficient,
and validating the want lines as we already do would give the same level
of assurance as "check against the hash of first phase response" I
outlined above, and would be much simpler thus more robust.
^ permalink raw reply
* Re: [PATCH/RFC 2/2] Provide a build time default-editor setting
From: Johannes Sixt @ 2009-10-29 20:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Roundy, Jonathan Nieder, Ben Walton, GIT List
In-Reply-To: <7viqdy6ii1.fsf@alter.siamese.dyndns.org>
On Donnerstag, 29. Oktober 2009, Junio C Hamano wrote:
> Johannes Sixt <j.sixt@viscovery.net> writes:
> > Something like below? Possible usage in shell scripts:
> >
> > editor=$(git var GIT_EDITOR)
> > "$editor" "$filename"
>
> I think we support GIT_EDITOR that is command path plus its initial
> command line arguments, so you do not want dq around $editor, right?
Yeah, whatever, I didn't take the time to think it through. But this may be an
opportunity to give some life back to the zombie that git-var currently is,
that is, to make it the plumbing that does value discovery for variables like
GIT_AUTHOR_INDENT, GIT_COMMITTER_IDENT, GIT_EDITOR, and perhaps also
GIT_PAGER.
-- Hannes
^ permalink raw reply
* finding the merge of two or more commits
From: E R @ 2009-10-29 21:12 UTC (permalink / raw)
To: git
Hi,
Given two commits c1 and c2, is it possible to ask git if there are
any commits in the repository that were created by either a sequence
of commands like:
git checkout c1
git merge c2
or:
git checkout c2
git merge c1
with any required conflict resolution?
That is, I don't want to merge c1 and c2 myself, but I want to know if
someone else has merged c1 and c2, performed any conflict resolution
and committed the result.
Thanks,
ER
^ permalink raw reply
* Re: finding the merge of two or more commits
From: Avery Pennarun @ 2009-10-29 21:34 UTC (permalink / raw)
To: E R; +Cc: git
In-Reply-To: <3a69fa7c0910291412l439f7f61vd3b55a77cd7e10b5@mail.gmail.com>
On Thu, Oct 29, 2009 at 5:12 PM, E R <pc88mxer@gmail.com> wrote:
> That is, I don't want to merge c1 and c2 myself, but I want to know if
> someone else has merged c1 and c2, performed any conflict resolution
> and committed the result.
Try this:
(git branch -a --contains c1; git branch -a --contains c2) | sort | uniq -d
It's not exactly pretty, but it works.
Have fun,
Avery
^ permalink raw reply
* [PATCH] More precise description of 'git describe --abbrev'
From: Gisle Aas @ 2009-10-29 21:38 UTC (permalink / raw)
To: git; +Cc: gitster
Also make the examples show what 'git describe' actually outputs
currently. I guess the default --abbrev value has been changed from 4
to 7 at some point.
Signed-off-by: Gisle Aas <gisle@aas.no>
---
Documentation/git-describe.txt | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index b231dbb..743eb95 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -44,7 +44,9 @@ OPTIONS
--abbrev=<n>::
Instead of using the default 7 hexadecimal digits as the
- abbreviated object name, use <n> digits.
+ abbreviated object name, use <n> digits or as many digits
+ are needed to form a unique object name. An <n> of 0
+ will suppress long format, only showing the closest tag.
--candidates=<n>::
Instead of considering only the 10 most recent tags as
@@ -68,8 +70,8 @@ OPTIONS
This is useful when you want to see parts of the commit object name
in "describe" output, even when the commit in question happens to be
a tagged version. Instead of just emitting the tag name, it will
- describe such a commit as v1.2-0-deadbeef (0th commit since tag v1.2
- that points at object deadbeef....).
+ describe such a commit as v1.2-0-gdeadbee (0th commit since tag v1.2
+ that points at object deadbee....).
--match <pattern>::
Only consider tags matching the given pattern (can be used to avoid
@@ -106,10 +108,10 @@ With --all, the command can use branch heads as
references, so
the output shows the reference path as well:
[torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2
- tags/v1.0.0-21-g975b
+ tags/v1.0.0-21-g975b3
[torvalds@g5 git]$ git describe --all HEAD^
- heads/lt/describe-7-g975b
+ heads/lt/describe-7-g975b31d
With --abbrev set to 0, the command can be used to find the
closest tagname without any suffix:
--
1.6.2.95.g934f7
^ permalink raw reply related
* Re: [RFC PATCH v4 03/26] pkt-line: Make packet_read_line easier to debug
From: Shawn O. Pearce @ 2009-10-29 21:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1vkm6id9.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> > The NUL assignment isn't about safe_read(), its about making the
> > block of 4 bytes read a proper C-style string so we can safely pass
> > it down into the snprintf that is within die().
>
> I knew and understood all of what you just said. static linelen[] is not
> about stack allocation. It's about letting the compiler initialize it to
> five NULs so that you do not have to assign NUL to its fifth place before
> you die. This removes one added line from your patch.
Thanks, I get it now. Patch amended.
--
Shawn.
^ permalink raw reply
* [PATCH 1/2] t/gitweb-lib.sh: Split gitweb output into headers and body
From: Jakub Narebski @ 2009-10-29 22:07 UTC (permalink / raw)
To: git; +Cc: Mark Rada, Jakub Narebski
In-Reply-To: <1256854062-25496-1-git-send-email-jnareb@gmail.com>
Save HTTP headers into gitweb.headers, and the body of message into
gitweb.body in gitweb_run()
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
I hope that this use of sed is portable enough.
Please take into account that HTTP headers part contains at least one
line: HTTP status.
t/gitweb-lib.sh | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
index 8452532..32b841d
--- a/t/gitweb-lib.sh
+++ b/t/gitweb-lib.sh
@@ -52,10 +52,14 @@ gitweb_run () {
rm -f gitweb.log &&
perl -- "$SCRIPT_NAME" \
>gitweb.output 2>gitweb.log &&
+ sed -e '/^\r$/q' <gitweb.output >gitweb.headers &&
+ sed -e '1,/^\r$/d' <gitweb.output >gitweb.body &&
if grep '^[[]' gitweb.log >/dev/null 2>&1; then false; else true; fi
# gitweb.log is left for debugging
- # gitweb.output is used to parse http output
+ # gitweb.output is used to parse HTTP output
+ # gitweb.headers contains only HTTP headers
+ # gitweb.body contains body of message, without headers
}
. ./test-lib.sh
--
1.6.5
^ permalink raw reply related
* [RFC/PATCH v6 2/2] gitweb: Smarter snapshot names
From: Jakub Narebski @ 2009-10-29 22:07 UTC (permalink / raw)
To: git; +Cc: Mark Rada, Shawn O. Pearce, Jakub Narebski
In-Reply-To: <1256854062-25496-2-git-send-email-jnareb@gmail.com>
From: Mark Rada <marada@uwaterloo.ca>
Teach gitweb how to produce nicer snapshot names by only using the
short hash id. If clients make requests using a tree-ish that is not
a partial or full SHA-1 hash, then the short hash will also be appended
to whatever they asked for. If clients request snapshot of a tag
(which means that $hash ('h') parameter has 'refs/tags/' prefix),
use only tag name.
This also includes tests cases for t9502-gitweb-standalone-parse-output.
Signed-off-by: Mark Rada <marada@uwaterloo.ca>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is currently an RFC because commit message does not describe
changes completely. Among others it doesn't describe current rules.
Also tests could be better described.
Changes since v5 (by Mark Rada):
- put common parts of git_get_full_hash and git_get_short_hash
into git_get_hash, do not do double verification
- separate finding snapshot name and prefix in snapshot_name()
subroutine, more smarts for snapshot name
- improved tests (use 'tar' snapshot format, testing new smarts,
testing prefix)
gitweb/gitweb.perl | 76 +++++++++++++++----
t/t9502-gitweb-standalone-parse-output.sh | 112 +++++++++++++++++++++++++++++
2 files changed, 172 insertions(+), 16 deletions(-)
create mode 100755 t/t9502-gitweb-standalone-parse-output.sh
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8d4a2ae..d8dfd95 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1983,16 +1983,27 @@ sub quote_command {
# get HEAD ref of given project as hash
sub git_get_head_hash {
- my $project = shift;
+ return git_get_full_hash(shift, 'HEAD');
+}
+
+sub git_get_full_hash {
+ return git_get_hash(@_);
+}
+
+sub git_get_short_hash {
+ return git_get_hash(@_, '--short=7');
+}
+
+sub git_get_hash {
+ my ($project, $hash, @options) = @_;
my $o_git_dir = $git_dir;
my $retval = undef;
$git_dir = "$projectroot/$project";
- if (open my $fd, "-|", git_cmd(), "rev-parse", "--verify", "HEAD") {
- my $head = <$fd>;
+ if (open my $fd, '-|', git_cmd(), 'rev-parse',
+ '--verify', '-q', @options, $hash) {
+ $retval = <$fd>;
+ chomp $retval if defined $retval;
close $fd;
- if (defined $head && $head =~ /^([0-9a-fA-F]{40})$/) {
- $retval = $1;
- }
}
if (defined $o_git_dir) {
$git_dir = $o_git_dir;
@@ -5179,6 +5190,43 @@ sub git_tree {
git_footer_html();
}
+sub snapshot_name {
+ my ($project, $hash) = @_;
+
+ # path/to/project.git -> project
+ # path/to/project/.git -> project
+ my $name = to_utf8($project);
+ $name =~ s,([^/])/*\.git$,$1,;
+ $name = basename($name);
+ # sanitize name
+ $name =~ s/[[:cntrl:]]/?/g;
+
+ my $ver = $hash;
+ if ($hash =~ /^[0-9a-fA-F]+$/) {
+ # shorten SHA-1 hash
+ my $full_hash = git_get_full_hash($project, $hash);
+ if ($full_hash =~ /^$hash/ && length($hash) > 7) {
+ $ver = git_get_short_hash($project, $hash);
+ }
+ } elsif ($hash =~ m!^refs/tags/(.*)$!) {
+ # tags don't need shortened SHA-1 hash
+ $ver = $1;
+ } else {
+ # branches and other need shortened SHA-1 hash
+ if ($hash =~ m!^refs/(?:heads|remotes)/(.*)$!) {
+ $ver = $1;
+ }
+ $ver .= '-' . git_get_short_hash($project, $hash);
+ }
+ # in case of hierarchical branch names
+ $ver =~ s!/!.!g;
+
+ # name = project-version_string
+ $name = "$name-$ver";
+
+ return wantarray ? ($name, $name) : $name;
+}
+
sub git_snapshot {
my $format = $input_params{'snapshot_format'};
if (!@snapshot_fmts) {
@@ -5203,24 +5251,20 @@ sub git_snapshot {
die_error(400, 'Object is not a tree-ish');
}
- my $name = $project;
- $name =~ s,([^/])/*\.git$,$1,;
- $name = basename($name);
- my $filename = to_utf8($name);
- $name =~ s/\047/\047\\\047\047/g;
- my $cmd;
- $filename .= "-$hash$known_snapshot_formats{$format}{'suffix'}";
- $cmd = quote_command(
+ my ($name, $prefix) = snapshot_name($project, $hash);
+ my $filename = "$name$known_snapshot_formats{$format}{'suffix'}";
+ my $cmd = quote_command(
git_cmd(), 'archive',
"--format=$known_snapshot_formats{$format}{'format'}",
- "--prefix=$name/", $hash);
+ "--prefix=$prefix/", $hash);
if (exists $known_snapshot_formats{$format}{'compressor'}) {
$cmd .= ' | ' . quote_command(@{$known_snapshot_formats{$format}{'compressor'}});
}
+ $filename =~ s/(["\\])/\\$1/g;
print $cgi->header(
-type => $known_snapshot_formats{$format}{'type'},
- -content_disposition => 'inline; filename="' . "$filename" . '"',
+ -content_disposition => 'inline; filename="' . $filename . '"',
-status => '200 OK');
open my $fd, "-|", $cmd
diff --git a/t/t9502-gitweb-standalone-parse-output.sh b/t/t9502-gitweb-standalone-parse-output.sh
new file mode 100755
index 0000000..fbf4e26
--- /dev/null
+++ b/t/t9502-gitweb-standalone-parse-output.sh
@@ -0,0 +1,112 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Mark Rada
+#
+
+test_description='gitweb as standalone script (parsing script output).
+
+This test runs gitweb (git web interface) as a CGI script from the
+commandline, and checks that it produces the correct output, either
+in the HTTP header or the actual script output.'
+
+
+. ./gitweb-lib.sh
+
+# ----------------------------------------------------------------------
+# snapshot file name
+
+cat >>gitweb_config.perl <<\EOF
+
+$known_snapshot_formats{'tar'} = {
+ 'display' => 'tar',
+ 'type' => 'application/x-tar',
+ 'suffix' => '.tar',
+ 'format' => 'tar',
+};
+
+$feature{'snapshot'}{'default'} = ['tar'];
+EOF
+
+test_expect_success setup '
+ test_commit first foo &&
+ git branch xx/test &&
+ FULL_ID=$(git rev-parse --verify HEAD) &&
+ SHORT_ID=$(git rev-parse --verify --short=7 HEAD)
+'
+test_debug '
+ echo "FULL_ID = $FULL_ID"
+ echo "SHORT_ID = $SHORT_ID"
+'
+
+test_expect_success 'snapshots: give full hash' '
+ gitweb_run "p=.git;a=snapshot;h=$FULL_ID;sf=tar" &&
+ grep ".git-$SHORT_ID.tar" gitweb.headers
+'
+test_debug 'cat gitweb.headers'
+test_debug 'cat gitweb.log'
+
+test_expect_success 'snapshots: give short hash' '
+ gitweb_run "p=.git;a=snapshot;h=$SHORT_ID;sf=tar" &&
+ grep ".git-$SHORT_ID.tar" gitweb.headers
+'
+test_debug 'cat gitweb.headers'
+
+test_expect_success 'snapshots: give almost full hash' '
+ ID=$(git rev-parse --short=30 HEAD) &&
+ gitweb_run "p=.git;a=snapshot;h=$ID;sf=tar" &&
+ grep ".git-$SHORT_ID.tar" gitweb.headers
+'
+test_debug 'cat gitweb.headers'
+
+test_expect_success 'snapshots: give HEAD' '
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tar" &&
+ grep ".git-HEAD-$SHORT_ID.tar" gitweb.headers
+'
+test_debug 'cat gitweb.headers'
+
+test_expect_success 'snapshots: give short branch name' '
+ gitweb_run "p=.git;a=snapshot;h=master;sf=tar" &&
+ ID=$(git rev-parse --verify --short=7 master) &&
+ grep ".git-master-$ID.tar" gitweb.headers
+'
+test_debug 'cat gitweb.headers'
+
+test_expect_success 'snapshots: give short tag name' '
+ gitweb_run "p=.git;a=snapshot;h=first;sf=tar" &&
+ ID=$(git rev-parse --verify --short=7 first) &&
+ grep ".git-first-$ID.tar" gitweb.headers
+'
+test_debug 'cat gitweb.headers'
+
+test_expect_success 'snapshots: give full branch name' '
+ gitweb_run "p=.git;a=snapshot;h=refs/heads/master;sf=tar" &&
+ ID=$(git rev-parse --verify --short=7 master) &&
+ grep ".git-master-$ID.tar" gitweb.headers
+'
+test_debug 'cat gitweb.headers'
+
+test_expect_success 'snapshots: give full tag name' '
+ gitweb_run "p=.git;a=snapshot;h=refs/tags/first;sf=tar" &&
+ grep ".git-first.tar" gitweb.headers
+'
+test_debug 'cat gitweb.headers'
+
+test_expect_success 'snapshots: give hierarchical branch name' '
+ gitweb_run "p=.git;a=snapshot;h=xx/test;sf=tar" &&
+ grep -v "filename=.*/" gitweb.headers
+'
+test_debug 'cat gitweb.headers'
+
+cat >expected <<EOF
+.git-HEAD-$SHORT_ID/
+.git-HEAD-$SHORT_ID/foo
+EOF
+test_expect_success 'snapshots: check prefix' '
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tar" &&
+ grep ".git-HEAD-$SHORT_ID.tar" gitweb.headers &&
+ "$TAR" tf gitweb.body >actual &&
+ test_cmp expected actual
+'
+test_debug 'cat gitweb.headers'
+
+test_done
--
1.6.5
^ permalink raw reply related
* [PATCH 0/2] gitweb: Smarter snapshot names
From: Jakub Narebski @ 2009-10-29 22:07 UTC (permalink / raw)
To: git; +Cc: Mark Rada, Jakub Narebski
This series is proposed proposed replacement for a single top commit
in 'mr/gitweb-snapshot' branch, which was merged into pu.
Those two patches are meant to replace the following commit:
b411a7a (gitweb: append short hash ids to snapshot files, 2009-09-26)
Jakub Narebski (1):
t/gitweb-lib.sh: Split gitweb output into headers and body
Mark Rada (1):
gitweb: Smarter snapshot names
(formerly: gitweb: append short hash ids to snapshot files)
Table of contents:
~~~~~~~~~~~~~~~~~~
[PATCH 1/2] t/gitweb-lib.sh: Split gitweb output into headers and body
[RFC/PATCH v6 2/2] gitweb: Smarter snapshot names
gitweb/gitweb.perl | 76 +++++++++++++++----
t/gitweb-lib.sh | 6 ++-
t/t9502-gitweb-standalone-parse-output.sh | 112 +++++++++++++++++++++++++++++
3 files changed, 177 insertions(+), 17 deletions(-)
create mode 100755 t/t9502-gitweb-standalone-parse-output.sh
--
Jakub Narebski
Poland
^ 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