* [PATCH v2 1/6] t2300: use documented technique to invoke git-sh-setup
From: Matthew Ogilvie @ 2009-11-30 6:19 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1259561971-25730-1-git-send-email-mmogilvi_git@miniinfo.net>
This is needed to allow the test suite to run against a standard
install bin directory instead of GIT_EXEC_PATH.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
t/t2300-cd-to-toplevel.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t2300-cd-to-toplevel.sh b/t/t2300-cd-to-toplevel.sh
index 3b01ad2..9965bc5 100755
--- a/t/t2300-cd-to-toplevel.sh
+++ b/t/t2300-cd-to-toplevel.sh
@@ -8,7 +8,7 @@ test_cd_to_toplevel () {
test_expect_success $3 "$2" '
(
cd '"'$1'"' &&
- . git-sh-setup &&
+ . "$(git --exec-path)"/git-sh-setup &&
cd_to_toplevel &&
[ "$(pwd -P)" = "$TOPLEVEL" ]
)
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH v2 0/6] Run test suite without dashed commands in PATH
From: Matthew Ogilvie @ 2009-11-30 6:19 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
This patch series runs the test suite without the dashed commands
in the PATH.
Changes since version 1:
- Added patch 3 that documents the pre-existing GIT_TEST_INSTALLED
feature.
- Rename what used to be "test-bin" directory as "bin-wrappers", to
more clearly describe what it is.
- Split off patch 6 (INSTALL documention) from patch
4 (was patch 3), describing how the bin-wrappers directory
is a very convenient way to manually test an uninstalled build.
I also reworded it a bit to mention the downsides. Junio
doesn't seem to agree this is useful; splitting it off makes
it easy to leave it out.
Not changed:
There was some discussion about not building the bin-wrappers directory
unless you are actually running tests. But I don't really think it
is worth the additional complexity to manage this. The "make all"
target is already building several full-up binaries to support the
test suite (not just the small sed-ed scripts that this adds). And any
such solution would need to deal with parallel execution locking
issues, as well as additional uglyness (either duplicating a list
of bindir executables within test-lib.sh itself, or calling into a
parent directory makefile that might already be running in
a grandparent process).
Matthew Ogilvie (6):
t2300: use documented technique to invoke git-sh-setup
t3409 t4107 t7406: use dashless commands
t/README: Document GIT_TEST_INSTALLED and GIT_TEST_EXEC_PATH
build dashless "bin-wrappers" directory similar to installed bindir
run test suite without dashed git-commands in PATH
INSTALL: document a simpler way to run uninstalled builds
.gitignore | 1 +
INSTALL | 11 +++++++-
Makefile | 49 ++++++++++++++++++++++++++---------
t/README | 21 +++++++++++++++
t/t2300-cd-to-toplevel.sh | 2 +-
t/t3409-rebase-preserve-merges.sh | 6 ++--
t/t4107-apply-ignore-whitespace.sh | 20 +++++++-------
t/t7406-submodule-update.sh | 4 +-
t/test-lib.sh | 33 +++++++++++++++---------
wrap-for-bin.sh | 15 +++++++++++
10 files changed, 120 insertions(+), 42 deletions(-)
create mode 100644 wrap-for-bin.sh
^ permalink raw reply
* [PATCH v2 5/6] run test suite without dashed git-commands in PATH
From: Matthew Ogilvie @ 2009-11-30 6:19 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1259561971-25730-5-git-send-email-mmogilvi_git@miniinfo.net>
Only put bin-wrappers in the PATH (not GIT_EXEC_PATH), to emulate the
default installed user environment, and ensure all the programs run
correctly in such an environment. This is now the default, although
it can be overridden with a --with-dashes test option when running
tests.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
t/README | 8 ++++++++
t/test-lib.sh | 33 +++++++++++++++++++++------------
2 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/t/README b/t/README
index 4e1d7dd..8c5d892 100644
--- a/t/README
+++ b/t/README
@@ -75,6 +75,14 @@ appropriately before running "make".
As the names depend on the tests' file names, it is safe to
run the tests with this option in parallel.
+--with-dashes::
+ By default tests are run without dashed forms of
+ commands (like git-commit) in the PATH (it only uses
+ wrappers from TOP/git-bin). Use this option to include TOP
+ in the PATH, which conains all the dashed forms of commands.
+ This option is currently implied by other options like --valgrind
+ and GIT_TEST_INSTALLED.
+
You can also set the GIT_TEST_INSTALLED environment variable to
the bindir of an existing git installation to test that installation.
You still need to have built this git sandbox, from which various
diff --git a/t/test-lib.sh b/t/test-lib.sh
index ec3336a..85377c8 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -105,6 +105,8 @@ do
verbose=t; shift ;;
-q|--q|--qu|--qui|--quie|--quiet)
quiet=t; shift ;;
+ --with-dashes)
+ with_dashes=t; shift ;;
--no-color)
color=; shift ;;
--no-python)
@@ -551,19 +553,8 @@ test_done () {
# Test the binaries we have just built. The tests are kept in
# t/ subdirectory and are run in 'trash directory' subdirectory.
TEST_DIRECTORY=$(pwd)
-if test -z "$valgrind"
+if test -n "$valgrind"
then
- if test -z "$GIT_TEST_INSTALLED"
- then
- PATH=$TEST_DIRECTORY/..:$PATH
- GIT_EXEC_PATH=$TEST_DIRECTORY/..
- else
- GIT_EXEC_PATH=$($GIT_TEST_INSTALLED/git --exec-path) ||
- error "Cannot run git from $GIT_TEST_INSTALLED."
- PATH=$GIT_TEST_INSTALLED:$TEST_DIRECTORY/..:$PATH
- GIT_EXEC_PATH=${GIT_TEST_EXEC_PATH:-$GIT_EXEC_PATH}
- fi
-else
make_symlink () {
test -h "$2" &&
test "$1" = "$(readlink "$2")" || {
@@ -625,6 +616,24 @@ else
PATH=$GIT_VALGRIND/bin:$PATH
GIT_EXEC_PATH=$GIT_VALGRIND/bin
export GIT_VALGRIND
+elif test -n "$GIT_TEST_INSTALLED" ; then
+ GIT_EXEC_PATH=$($GIT_TEST_INSTALLED/git --exec-path) ||
+ error "Cannot run git from $GIT_TEST_INSTALLED."
+ PATH=$GIT_TEST_INSTALLED:$TEST_DIRECTORY/..:$PATH
+ GIT_EXEC_PATH=${GIT_TEST_EXEC_PATH:-$GIT_EXEC_PATH}
+else # normal case, use ../bin-wrappers only unless $with_dashes:
+ git_bin_dir="$TEST_DIRECTORY/../bin-wrappers"
+ if ! test -x "$git_bin_dir/git" ; then
+ if test -z "$with_dashes" ; then
+ say "$git_bin_dir/git is not executable; using GIT_EXEC_PATH"
+ fi
+ with_dashes=t
+ fi
+ PATH="$git_bin_dir:$PATH"
+ GIT_EXEC_PATH=$TEST_DIRECTORY/..
+ if test -n "$with_dashes" ; then
+ PATH="$TEST_DIRECTORY/..:$PATH"
+ fi
fi
GIT_TEMPLATE_DIR=$(pwd)/../templates/blt
unset GIT_CONFIG
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH v2 4/6] build dashless "bin-wrappers" directory similar to installed bindir
From: Matthew Ogilvie @ 2009-11-30 6:19 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1259561971-25730-4-git-send-email-mmogilvi_git@miniinfo.net>
The new bin-wrappers directory contains wrapper scripts
for executables that will be installed into the standard
bindir. It explicitly does not contain most dashed-commands.
The scripts automatically set environment variables to run out
of the source tree, not the installed directory.
This will allow running the test suite without dashed commands in
the PATH. It also provides a simplified way to test run custom
built git executables without installing them first.
bin-wrappers also contains wrappers for some test suite support
executables, where the test suite will soon make use of them.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
There was some discussion of only building bin-wrappers when
actually running tests, but I don't think it is worth the
extra complexity. See the cover letter (0/6).
.gitignore | 1 +
Makefile | 49 ++++++++++++++++++++++++++++++++++++-------------
wrap-for-bin.sh | 15 +++++++++++++++
3 files changed, 52 insertions(+), 13 deletions(-)
create mode 100644 wrap-for-bin.sh
diff --git a/.gitignore b/.gitignore
index ac02a58..5d32289 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,6 +2,7 @@
/GIT-CFLAGS
/GIT-GUI-VARS
/GIT-VERSION-FILE
+/bin-wrappers/
/git
/git-add
/git-add--interactive
diff --git a/Makefile b/Makefile
index 5a0b3d4..77892ec 100644
--- a/Makefile
+++ b/Makefile
@@ -416,6 +416,15 @@ ALL_PROGRAMS = $(PROGRAMS) $(SCRIPTS)
# what 'all' will build but not install in gitexecdir
OTHER_PROGRAMS = git$X
+# what test wrappers are needed and 'install' will install, in bindir
+BINDIR_PROGRAMS_NEED_X += git
+BINDIR_PROGRAMS_NEED_X += git-upload-pack
+BINDIR_PROGRAMS_NEED_X += git-receive-pack
+BINDIR_PROGRAMS_NEED_X += git-upload-archive
+BINDIR_PROGRAMS_NEED_X += git-shell
+
+BINDIR_PROGRAMS_NO_X += git-cvsserver
+
# Set paths to tools early so that they can be used for version tests.
ifndef SHELL_PATH
SHELL_PATH = /bin/sh
@@ -1690,19 +1699,30 @@ endif
### Testing rules
-TEST_PROGRAMS += test-chmtime$X
-TEST_PROGRAMS += test-ctype$X
-TEST_PROGRAMS += test-date$X
-TEST_PROGRAMS += test-delta$X
-TEST_PROGRAMS += test-dump-cache-tree$X
-TEST_PROGRAMS += test-genrandom$X
-TEST_PROGRAMS += test-match-trees$X
-TEST_PROGRAMS += test-parse-options$X
-TEST_PROGRAMS += test-path-utils$X
-TEST_PROGRAMS += test-sha1$X
-TEST_PROGRAMS += test-sigchain$X
+TEST_PROGRAMS_NEED_X += test-chmtime
+TEST_PROGRAMS_NEED_X += test-ctype
+TEST_PROGRAMS_NEED_X += test-date
+TEST_PROGRAMS_NEED_X += test-delta
+TEST_PROGRAMS_NEED_X += test-dump-cache-tree
+TEST_PROGRAMS_NEED_X += test-genrandom
+TEST_PROGRAMS_NEED_X += test-match-trees
+TEST_PROGRAMS_NEED_X += test-parse-options
+TEST_PROGRAMS_NEED_X += test-path-utils
+TEST_PROGRAMS_NEED_X += test-sha1
+TEST_PROGRAMS_NEED_X += test-sigchain
+
+TEST_PROGRAMS = $(patsubst %,%$X,$(TEST_PROGRAMS_NEED_X))
-all:: $(TEST_PROGRAMS)
+test_bindir_programs := $(patsubst %,bin-wrappers/%,$(BINDIR_PROGRAMS_NEED_X) $(BINDIR_PROGRAMS_NO_X) $(TEST_PROGRAMS_NEED_X))
+
+all:: $(TEST_PROGRAMS) $(test_bindir_programs)
+
+bin-wrappers/%: wrap-for-bin.sh
+ @mkdir -p bin-wrappers
+ $(QUIET_GEN)sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
+ -e 's|__GIT_EXEC_PATH__|$(shell pwd)|' \
+ -e 's|__PROG__|$(@F)|' < $< > $@ && \
+ chmod +x $@
# GNU make supports exporting all variables by "export" without parameters.
# However, the environment gets quite big, and some programs have problems
@@ -1763,11 +1783,13 @@ endif
gitexec_instdir_SQ = $(subst ','\'',$(gitexec_instdir))
export gitexec_instdir
+install_bindir_programs := $(patsubst %,%$X,$(BINDIR_PROGRAMS_NEED_X)) $(BINDIR_PROGRAMS_NO_X)
+
install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
- $(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X git-cvsserver '$(DESTDIR_SQ)$(bindir_SQ)'
+ $(INSTALL) $(install_bindir_programs) '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
ifndef NO_PERL
$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
@@ -1878,6 +1900,7 @@ clean:
$(LIB_FILE) $(XDIFF_LIB)
$(RM) $(ALL_PROGRAMS) $(BUILT_INS) git$X
$(RM) $(TEST_PROGRAMS)
+ $(RM) -r bin-wrappers
$(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags cscope*
$(RM) -r autom4te.cache
$(RM) config.log config.mak.autogen config.mak.append config.status config.cache
diff --git a/wrap-for-bin.sh b/wrap-for-bin.sh
new file mode 100644
index 0000000..ee2bc98
--- /dev/null
+++ b/wrap-for-bin.sh
@@ -0,0 +1,15 @@
+#!/bin/sh
+
+# wrap-for-bin.sh: Template for git executable wrapper scripts
+# to run test suite against sandbox, but with only bindir-installed
+# executables in PATH. The Makefile copies this into various
+# files in bin-wrappers, substituting
+# __GIT_EXEC_PATH__ and __PROG__.
+
+GIT_EXEC_PATH="__GIT_EXEC_PATH__"
+GIT_TEMPLATE_DIR="__GIT_EXEC_PATH__/templates/blt"
+GITPERLLIB="__GIT_EXEC_PATH__/perl/blib/lib"
+PATH="__GIT_EXEC_PATH__/bin-wrappers:$PATH"
+export GIT_EXEC_PATH GIT_TEMPLATE_DIR GITPERLLIB PATH
+
+exec "${GIT_EXEC_PATH}/__PROG__" "$@"
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH v2 3/6] t/README: Document GIT_TEST_INSTALLED and GIT_TEST_EXEC_PATH
From: Matthew Ogilvie @ 2009-11-30 6:19 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1259561971-25730-3-git-send-email-mmogilvi_git@miniinfo.net>
These were added without documentation in 2009-03-16 (6720721).
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
t/README | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/t/README b/t/README
index d8f6c7d..4e1d7dd 100644
--- a/t/README
+++ b/t/README
@@ -75,6 +75,19 @@ appropriately before running "make".
As the names depend on the tests' file names, it is safe to
run the tests with this option in parallel.
+You can also set the GIT_TEST_INSTALLED environment variable to
+the bindir of an existing git installation to test that installation.
+You still need to have built this git sandbox, from which various
+test-* support programs, templates, and perl libraries are used.
+If your installed git is incomplete, it will silently test parts of
+your built version instead.
+
+When using GIT_TEST_INSTALLED, you can also set GIT_TEST_EXEC_PATH to
+override the location of the dashed-form subcommands (what
+GIT_EXEC_PATH would be used for during normal operation).
+GIT_TEST_EXEC_PATH defaults to `$GIT_TEST_INSTALLED/git --exec-path`.
+
+
Skipping Tests
--------------
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH v2 2/6] t3409 t4107 t7406: use dashless commands
From: Matthew Ogilvie @ 2009-11-30 6:19 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1259561971-25730-2-git-send-email-mmogilvi_git@miniinfo.net>
This is needed to allow test suite to run against a standard
install bin directory instead of GIT_EXEC_PATH.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
t/t3409-rebase-preserve-merges.sh | 6 +++---
t/t4107-apply-ignore-whitespace.sh | 20 ++++++++++----------
t/t7406-submodule-update.sh | 4 ++--
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/t/t3409-rebase-preserve-merges.sh b/t/t3409-rebase-preserve-merges.sh
index 297d165..8f785e7 100755
--- a/t/t3409-rebase-preserve-merges.sh
+++ b/t/t3409-rebase-preserve-merges.sh
@@ -32,14 +32,14 @@ export GIT_AUTHOR_EMAIL
test_expect_success 'setup for merge-preserving rebase' \
'echo First > A &&
git add A &&
- git-commit -m "Add A1" &&
+ git commit -m "Add A1" &&
git checkout -b topic &&
echo Second > B &&
git add B &&
- git-commit -m "Add B1" &&
+ git commit -m "Add B1" &&
git checkout -f master &&
echo Third >> A &&
- git-commit -a -m "Modify A2" &&
+ git commit -a -m "Modify A2" &&
git clone ./. clone1 &&
cd clone1 &&
diff --git a/t/t4107-apply-ignore-whitespace.sh b/t/t4107-apply-ignore-whitespace.sh
index 484654d..b04fc8f 100755
--- a/t/t4107-apply-ignore-whitespace.sh
+++ b/t/t4107-apply-ignore-whitespace.sh
@@ -136,37 +136,37 @@ void print_int(int num) {
EOF
test_expect_success 'file creation' '
- git-apply patch1.patch
+ git apply patch1.patch
'
test_expect_success 'patch2 fails (retab)' '
- test_must_fail git-apply patch2.patch
+ test_must_fail git apply patch2.patch
'
test_expect_success 'patch2 applies with --ignore-whitespace' '
- git-apply --ignore-whitespace patch2.patch
+ git apply --ignore-whitespace patch2.patch
'
test_expect_success 'patch2 reverse applies with --ignore-space-change' '
- git-apply -R --ignore-space-change patch2.patch
+ git apply -R --ignore-space-change patch2.patch
'
git config apply.ignorewhitespace change
test_expect_success 'patch2 applies (apply.ignorewhitespace = change)' '
- git-apply patch2.patch
+ git apply patch2.patch
'
test_expect_success 'patch3 fails (missing string at EOL)' '
- test_must_fail git-apply patch3.patch
+ test_must_fail git apply patch3.patch
'
test_expect_success 'patch4 fails (missing EOL at EOF)' '
- test_must_fail git-apply patch4.patch
+ test_must_fail git apply patch4.patch
'
test_expect_success 'patch5 applies (leading whitespace)' '
- git-apply patch5.patch
+ git apply patch5.patch
'
test_expect_success 'patches do not mangle whitespace' '
@@ -175,11 +175,11 @@ test_expect_success 'patches do not mangle whitespace' '
test_expect_success 're-create file (with --ignore-whitespace)' '
rm -f main.c &&
- git-apply patch1.patch
+ git apply patch1.patch
'
test_expect_success 'patch5 fails (--no-ignore-whitespace)' '
- test_must_fail git-apply --no-ignore-whitespace patch5.patch
+ test_must_fail git apply --no-ignore-whitespace patch5.patch
'
test_done
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index 2d33d9e..8e2449d 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -14,8 +14,8 @@ submodule and "git submodule update --rebase/--merge" does not detach the HEAD.
compare_head()
{
- sha_master=`git-rev-list --max-count=1 master`
- sha_head=`git-rev-list --max-count=1 HEAD`
+ sha_master=`git rev-list --max-count=1 master`
+ sha_head=`git rev-list --max-count=1 HEAD`
test "$sha_master" = "$sha_head"
}
--
1.6.4.GIT
^ permalink raw reply related
* Re: [PATCH 3/8] git-merge-recursive-{ours,theirs}
From: Junio C Hamano @ 2009-11-30 6:21 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
In-Reply-To: <32541b130911261405q6564d8f2o30b7d7fd6f708d05@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> writes:
>> - I think we should avoid adding the extra argument to ll_merge_fn() by
>> combining virtual_ancestor and favor into one "flags" parameter. If
>> you do so, we do not have to change the callsites again next time we
>> need to add new optional features that needs only a few bits.
>>
>> I vaguely recall that I did the counterpart of this patch that way
>> exactly for the above reason, but it is more than a year ago, so maybe
>> I didn't do it that way.
>
> You did do that, in fact,... <<rationale omitted>>
Think of the "flag" parameter as a mini "struct option". When you add a
feature to a function at or near the leaf level of call chains that are
potentially deep, you add one element to the option structure, and take
advantage of the fact that existing callers put a sane default value in
the new field, i.e. 0, by doing a "memset(&opt, 0, sizeof(opt))" already,
so that the callsites that do not even have to know about the new feature
will keep working the same old way without breakage. You saw this exact
pattern in the [1/8] patch in your series to cram new "favor this side"
information into an existing parameter.
As you mentioned, sometimes changing function signature is preferred to
catch semantic differences at compilation time. The report given by the
compiler of extra or missing parameter at the call site is a wonderful way
to find out that you forgot to convert them to the new semantics of the
function. This also helps when there is an in-flight patch that adds a
new callsite to the function whose semantics you are changing. The
semantic conflict is caught when compiling the result of a merge with a
branch with such a patch. It is a trick worth knowing about.
The approach however cuts both ways. When you are adding an optional
feature that is used only in a very few call sites, the semantic merge
conflict resulting from such a function signature change is rarely worth
it.
As long as you choose the default "no-op" value carefully enough so that
existing callers will naturally use it without modification, the old code
will work the way they did before the new optional feature was added. In
other words, "let's implement this as purely an opt-in feature" is often
preferrable over "let's force semantic conflict and compilation failure,
just in case existing callsites may also want to trigger this new
feature".
That is why [1/8] patch in your series uses 0 to mean "don't do the funny
'favor' trick, but just leave the conflicts there".
I've queued the series with minor fixes to 'pu' and pushed it out.
^ permalink raw reply
* [PATCH v2 6/6] INSTALL: document a simpler way to run uninstalled builds
From: Matthew Ogilvie @ 2009-11-30 6:19 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1259561971-25730-6-git-send-email-mmogilvi_git@miniinfo.net>
The new scripts automatically saved in the bin-wrappers
directory allow you test run a build when you have neither installed
git nor tweaked environment variables. Mention this in INSTALL,
along with the slight performance issue of doing so.
This can be especially handy for manually testing
network-invoked git (from ssh, web servers, or similar), but
it is also handy with a plain command prompt.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
INSTALL | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/INSTALL b/INSTALL
index be504c9..ee718c6 100644
--- a/INSTALL
+++ b/INSTALL
@@ -39,7 +39,19 @@ Issues of note:
with --disable-transition option to avoid this.
- You can use git after building but without installing if you
- wanted to. Various git commands need to find other git
+ want to.
+
+ The simplest option for running some manual tests of a build
+ before installing it is to use the wrapper scripts that are built
+ and saved into `pwd`/bin-wrappers. Either invoke the scripts in
+ bin-wrappers using their full paths, put bin-wrappers in your
+ PATH, or copy/symlink just the bin-wrappers scripts into somewhere
+ already in your PATH. But this option is slightly inefficient,
+ so for a more permanent solution we recommend either installing
+ git (you can set a prefix to install right next to your
+ build directory), or use the alternative below.
+
+ Alternatively, various git commands need to find other git
commands and scripts to do their work, so you would need to
arrange a few environment variables to tell them that their
friends will be found in your built source area instead of at
--
1.6.4.GIT
^ permalink raw reply related
* Re: [PATCH v2 4/6] build dashless "bin-wrappers" directory similar to installed bindir
From: Junio C Hamano @ 2009-11-30 6:28 UTC (permalink / raw)
To: Matthew Ogilvie; +Cc: git
In-Reply-To: <1259561971-25730-5-git-send-email-mmogilvi_git@miniinfo.net>
Matthew Ogilvie <mmogilvi_git@miniinfo.net> writes:
> diff --git a/wrap-for-bin.sh b/wrap-for-bin.sh
> new file mode 100644
> index 0000000..ee2bc98
> --- /dev/null
> +++ b/wrap-for-bin.sh
> @@ -0,0 +1,15 @@
> +#!/bin/sh
> +
> +# wrap-for-bin.sh: Template for git executable wrapper scripts
> +# to run test suite against sandbox, but with only bindir-installed
> +# executables in PATH. The Makefile copies this into various
> +# files in bin-wrappers, substituting
> +# __GIT_EXEC_PATH__ and __PROG__.
> +
> +GIT_EXEC_PATH="__GIT_EXEC_PATH__"
> +GIT_TEMPLATE_DIR="__GIT_EXEC_PATH__/templates/blt"
> +GITPERLLIB="__GIT_EXEC_PATH__/perl/blib/lib"
> +PATH="__GIT_EXEC_PATH__/bin-wrappers:$PATH"
> +export GIT_EXEC_PATH GIT_TEMPLATE_DIR GITPERLLIB PATH
> +
> +exec "${GIT_EXEC_PATH}/__PROG__" "$@"
Two issues, one minor and one not so minor but not grave:
- Everywhere else we seem to use "@@UPPERCASE_NAME@@" not
double-underscore as placeholders like the above.
- @@PROG@@ is under our control and it is easy for us to guarantee that
it won't have any funny letters, but GIT_EXEC_PATH is not. Is it safe
to do a simple-minded "sed" replacement, or does it need the usual sq
trick employed in the other replacement in our Makefile?
^ permalink raw reply
* git include
From: Rakotomandimby Mihamina @ 2009-11-30 6:41 UTC (permalink / raw)
To: git
Hi all,
I would like to track only *.ml files and ignore all others.
Is there a way to do that in .gitignore?
Thanks.
--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 33 11 207 36
^ permalink raw reply
* Re: git include
From: Nguyen Thai Ngoc Duy @ 2009-11-30 6:45 UTC (permalink / raw)
To: Rakotomandimby Mihamina; +Cc: git
In-Reply-To: <4B136932.9000908@gulfsat.mg>
On Mon, Nov 30, 2009 at 1:41 PM, Rakotomandimby Mihamina
<mihamina@gulfsat.mg> wrote:
> Hi all,
>
> I would like to track only *.ml files and ignore all others.
> Is there a way to do that in .gitignore?
This .gitignore should work (of course for new files only):
-->8--
*
!*.ml
-->8--
--
Duy
^ permalink raw reply
* Re: [PATCH v2 6/6] INSTALL: document a simpler way to run uninstalled builds
From: Junio C Hamano @ 2009-11-30 6:48 UTC (permalink / raw)
To: Matthew Ogilvie; +Cc: git
In-Reply-To: <1259561971-25730-7-git-send-email-mmogilvi_git@miniinfo.net>
Matthew Ogilvie <mmogilvi_git@miniinfo.net> writes:
> diff --git a/INSTALL b/INSTALL
> index be504c9..ee718c6 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -39,7 +39,19 @@ Issues of note:
> with --disable-transition option to avoid this.
>
> - You can use git after building but without installing if you
> - wanted to. Various git commands need to find other git
> + want to.
> +
> + The simplest option for running some manual tests of a build
> + before installing it is to use the wrapper scripts that are built
> + and saved into `pwd`/bin-wrappers. Either invoke the scripts in
> + bin-wrappers using their full paths, put bin-wrappers in your
> + PATH, or copy/symlink just the bin-wrappers scripts into somewhere
> + already in your PATH. But this option is slightly inefficient,
> + so for a more permanent solution we recommend either installing
> + git (you can set a prefix to install right next to your
> + build directory), or use the alternative below.
Drop "simplest" and "slightly".
I think you forgot to mention an important improvement you made since the
earlier iteration on the wrap-for-bin script in the cover letter. With
the new wrap-for-bin, we do not have to worry about the case a random
binary in the directory is run without first adding anything to user's
$PATH anymore, no?
With that change, this round's implementation deserves to be recommended
as the new preferred way to run "use after building without installing", I
think. So how about making the text like this?
You can use git after building but without installing if you want to
test drive it. Simply run git found in bin-wrappers directory in the
build directory, or prepend that directory to your $PATH. This
however is less efficient than running an installed git, as you always
need an extra fork+exec to run any git subcommand.
It is still possible to use git without installing by setting a few
environment variables, which was the way this was done traditionally.
But using git found in bin-wrappers directory in the build directory
is far simpler. Just for a historical reference, the old way went
like this:
GIT_EXEC_PATH=`pwd`
PATH=`pwd`:$PATH
GITPERLLIB=`pwd`/perl/blib/lib
export GIT_EXEC_PATH PATH GITPERLLIB
^ permalink raw reply
* Re: [PATCH v3] Give the hunk comment its own color
From: Bert Wesarg @ 2009-11-30 7:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <36ca99e90911280408v186777f1h22254744fb61bf1f@mail.gmail.com>
>> /* blank before the func header */
>> for (cp = ep; ep - line < len; ep++)
>> if (*ep != ' ' && *ep != 't')
> Please check that its really an *ep != '\t'. Its wrong in this mail, I
> see only an *ep != 't'.
Obviously, you have not checked it. Please squash this in:
diff --git i/diff.c w/diff.c
index eaa1983..e126304 100644
--- i/diff.c
+++ w/diff.c
@@ -376,7 +376,7 @@ static void emit_hunk_header(struct emit_callback *ecbdata,
/* blank before the func header */
for (cp = ep; ep - line < len; ep++)
- if (*ep != ' ' && *ep != 't')
+ if (*ep != ' ' && *ep != '\t')
break;
if (ep != cp)
emit_line(ecbdata->file, plain, reset, cp, ep - cp);
Bert
^ permalink raw reply related
* Re: [PATCH 3/4] build dashless "test-bin" directory similar to installed bindir
From: Nanako Shiraishi @ 2009-11-30 7:07 UTC (permalink / raw)
To: Matthew Ogilvie; +Cc: Junio C Hamano, git, peff
In-Reply-To: <20091129025251.GA1771@comcast.net>
Quoting Matthew Ogilvie <mmogilvi_git@miniinfo.net>
> 4. Rename test-bin. Perhaps "bin-wrappers", "bin-dashless",
> "bin-install", "bin", or "bindir". Any preferences?
"gitrun" or "rungit"?
I prefer the latter because too many files begin with "git" after compiling.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH v3] Give the hunk comment its own color
From: Junio C Hamano @ 2009-11-30 7:15 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Junio C Hamano, Jeff King, git
In-Reply-To: <36ca99e90911292307w769913fdn1f610eeb065b41e@mail.gmail.com>
Sorry, but I think the fix is already in 'next', no?
^ permalink raw reply
* Re: [PATCH v2 0/6] Run test suite without dashed commands in PATH
From: Junio C Hamano @ 2009-11-30 7:16 UTC (permalink / raw)
To: Matthew Ogilvie; +Cc: git
In-Reply-To: <1259561971-25730-1-git-send-email-mmogilvi_git@miniinfo.net>
I added t9150 to your second patch and pushed the result out on 'pu'.
^ permalink raw reply
* Re: [PATCH] reset: add --quiet option
From: Junio C Hamano @ 2009-11-30 7:17 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Felipe Contreras, git
In-Reply-To: <1259543939.5679.5.camel@swboyd-laptop>
Stephen Boyd <bebarino@gmail.com> writes:
> Why not just OPT__QUIET?
Good question. I was in no hurry to queue this, so Felipe has plenty time
to respond.
^ permalink raw reply
* Re: git include
From: Armen Baghumian @ 2009-11-30 7:10 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0911292245t6b18c238s2859d2cbd5dd26be@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 480 bytes --]
Probably you want to add .gitignore too
*
!*.ml
!.gitignore
On Mon, 30 Nov 2009 13:45:57 +0700
Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Mon, Nov 30, 2009 at 1:41 PM, Rakotomandimby Mihamina
> <mihamina@gulfsat.mg> wrote:
> > Hi all,
> >
> > I would like to track only *.ml files and ignore all others.
> > Is there a way to do that in .gitignore?
>
> This .gitignore should work (of course for new files only):
> -->8--
> *
> !*.ml
> -->8--
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git include
From: Nguyen Thai Ngoc Duy @ 2009-11-30 7:29 UTC (permalink / raw)
To: Armen Baghumian; +Cc: git
In-Reply-To: <20091130104055.3c3274f5@Office>
On Mon, Nov 30, 2009 at 2:10 PM, Armen Baghumian
<armen@opensourceclub.org> wrote:
>
> Probably you want to add .gitignore too
>
> *
> !*.ml
> !.gitignore
In that case it should be "!.git*" as you may miss .gitattributes or .gitmodules
--
Duy
^ permalink raw reply
* Re: git include
From: Rakotomandimby Mihamina @ 2009-11-30 7:33 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0911292329p672572dcmbe0c01912d50fd0a@mail.gmail.com>
11/30/2009 10:29 AM, Nguyen Thai Ngoc Duy::
>> Probably you want to add .gitignore too
>> *
>> !*.ml
>> !.gitignore
> In that case it should be "!.git*" as you may miss .gitattributes or .gitmodules
*
!*.ml
Is perfect for me.
Thanks, guys.
--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 33 11 207 36
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #07; Sun, 29)
From: Junio C Hamano @ 2009-11-30 7:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vocmlbq8d.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> This will be the last update before deciding what should go in 1.6.6-rc1
> and describes my current thinking.
I do not want to decide unilaterally what will be in and what will be left
out of 1.6.6, so here is a seocnd call for comments.
I said "Perhaps merge it to 'master' before 1.6.6-rc1?" for these:
> * uk/maint-shortlog-encoding (2009-11-25) 1 commit.
> * fc/send-email-envelope (2009-11-26) 2 commits.
> * jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
> * tr/reset-checkout-patch (2009-11-19) 1 commit.
> * em/commit-claim (2009-11-04) 1 commit
> * cc/bisect-doc (2009-11-08) 1 commit
> * jc/pretty-lf (2009-10-04) 1 commit.
> * ns/send-email-no-chain-reply-to (2009-11-29) 1 commit
I didn't say so in the message but I think this is Ok for 1.6.6-rc1.
> * bw/diff-color-hunk-header (2009-11-27) 2 commits
I would love to see necessary fix-ups to make them suitable and include in
the 1.6.6 final for these:
> * jn/gitweb-blame (2009-11-24) 8 commits.
I am inclined to keep the rest out of 1.6.6.
Even though I did it myself, I am ambivalent about the diff.bwoutputonly
anti-procrastination measure. The send-email one looked fine and is a
welcome addition to the "don't surprise users" effort to prepare for 1.7.0,
and diff.bwoutputonly is in a sense in a similar spirit, but an option to
keep an old and broken semantics feels somewhat wrong.
Also anybody has comments on the part for preparing users for 1.7.0 in the
draft release notes?
^ permalink raw reply
* Re: [PATCH v3] Give the hunk comment its own color
From: Bert Wesarg @ 2009-11-30 7:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7v4ooczdoe.fsf@alter.siamese.dyndns.org>
On Mon, Nov 30, 2009 at 08:15, Junio C Hamano <gitster@pobox.com> wrote:
> Sorry, but I think the fix is already in 'next', no?
Yes it is, should have fetched first. sorry.
^ permalink raw reply
* Re: [PATCH v3] Give the hunk comment its own color
From: Junio C Hamano @ 2009-11-30 7:47 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Junio C Hamano, Jeff King, git
In-Reply-To: <36ca99e90911292341o524840ebo47d79f06b1588d5c@mail.gmail.com>
Bert Wesarg <bert.wesarg@googlemail.com> writes:
> On Mon, Nov 30, 2009 at 08:15, Junio C Hamano <gitster@pobox.com> wrote:
>> Sorry, but I think the fix is already in 'next', no?
> Yes it is, should have fetched first. sorry.
Don't be sorry; thanks for catching it.
The current 'next' branch has the original commit with a botched rewrite
by mine, and also a fixed commit, so unfortunately shortlog would list the
patch twice. I'll merge the updated (i.e. rewound and then rebuilt) tip
of the topic branch when the topic graduates to the master (hopefully
before 1.6.6-rc1), so we won't see the botched one in the end result.
^ permalink raw reply
* Re: [PATCH] Update $GIT_DIR/remotes to $GIT_DIR/refs/remotes in docs
From: Nazri Ramliy @ 2009-11-30 7:48 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091130050333.GA26585@coredump.intra.peff.net>
On Mon, Nov 30, 2009 at 1:03 PM, Jeff King <peff@peff.net> wrote:
> Er, what? $GIT_DIR/remotes/ and $GIT_DIR/refs/remotes/ are not even
> remotely the same thing. The former holds information about how to
> contact remotes (but that information is usually held in the config file
> these days). The latter holds any tracking refs we have fetched from
> the remotes.
Erg.. thanks for the enlightenment.
I was reading 'git help remote' while attempting to change my local git
repo from tracking
http://www.kernel.org/pub/scm/git/git.git
to
git://git.kernel.org/pub/scm/git/git.git
and noticed that the documentation refers to $GIT_DIR/remotes and
(wrongly) thought that it meant $GIT_DIR/refs/remotes.
Sorry for the noise.
Nazri.
^ permalink raw reply
* [PATCH] tests: handle NO_PYTHON setting
From: Jeff King @ 2009-11-30 7:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, git
Without this, test-lib checks that the git_remote_helpers
directory has been built. However, if we are building
without python, we will not have done anything at all in
that directory, and test-lib's sanity check will fail.
Signed-off-by: Jeff King <peff@peff.net>
---
On top of sr/vcs-helper.
This feels a little funny for NO_PYTHON to mean "no remote helpers at
all". But that is the way the Makefile is set up, since we seem to have
only python helpers.
Makefile | 1 +
t/test-lib.sh | 2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 42744a4..443565e 100644
--- a/Makefile
+++ b/Makefile
@@ -1743,6 +1743,7 @@ GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
@echo TAR=\''$(subst ','\'',$(subst ','\'',$(TAR)))'\' >>$@
@echo NO_CURL=\''$(subst ','\'',$(subst ','\'',$(NO_CURL)))'\' >>$@
@echo NO_PERL=\''$(subst ','\'',$(subst ','\'',$(NO_PERL)))'\' >>$@
+ @echo NO_PYTHON=\''$(subst ','\'',$(subst ','\'',$(NO_PYTHON)))'\' >>$@
### Detect Tck/Tk interpreter path changes
ifndef NO_TCLTK
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 4a40520..ca0839c 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -638,7 +638,7 @@ test -d ../templates/blt || {
error "You haven't built things yet, have you?"
}
-if test -z "$GIT_TEST_INSTALLED"
+if test -z "$GIT_TEST_INSTALLED" && test -z "$NO_PYTHON"
then
GITPYTHONLIB="$(pwd)/../git_remote_helpers/build/lib"
export GITPYTHONLIB
--
1.6.6.rc0.327.gd49b
^ permalink raw reply related
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