* Re: How to merge in different order?
From: Jeff King @ 2009-04-03 16:31 UTC (permalink / raw)
To: Josef Wolf, git
In-Reply-To: <20090403161208.GC28619@raven.wolf.lan>
On Fri, Apr 03, 2009 at 06:12:08PM +0200, Josef Wolf wrote:
> Given a branch that looks like
>
> A1 A2 A3 A4 A5
>
> I would like to merge into another branch in the order
>
> A1 A3 A4 A2 A5
>
> When I merge A3, then A2 is merged also. git-merge don't seem
> to have an option to omit slurping older commits?
Right. Remember that git represents history as a directed graph, so a
merge is really just another commit saying "I include all history
leading up to these two commits". There is no way to say "I include the
history leading up to these commits, minus some other commits".
If you just want to throw away A2, you can "git revert" it, then merge.
But what you probably want to do is rewrite the history of your branch
to re-order the commits. You can do this with "git rebase -i". Like any
history rewriting, this can cause difficulties for people who you have
already shared the branch with (because it will replace the commits that
they already have with 5 _new_ commits that just happen to do more or
less the same thing).
If you have already shared the branch, you may just want to cherry-pick
the changes you want (using "git cherry-pick") onto your other branch.
-Peff
^ permalink raw reply
* Re: [PATCH] NO_PERL support
From: Jeff King @ 2009-04-03 17:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin H. Johnson, Git Mailing List
In-Reply-To: <7vljqhaemm.fsf@gitster.siamese.dyndns.org>
On Fri, Apr 03, 2009 at 09:25:21AM -0700, Junio C Hamano wrote:
> While I do not mind omitting whole programs in fringes like you did for
> archimport and relink, I *really* do not like this particular change (and
> any change to the C code).
>
> I'd rather see something along the lines of:
>
> if NO_PERL
> git-add--interactive: unimplemented.sh
> rm -f $@+ $@
> cat $? >$@+
> chmod +x $@+
> mv $@+ $@
> else
> git-add--interactive: git-add--interactive.perl
> ... usual .perl to script rule applies
> endif
>
> and ship:
>
> #!/bin/sh
> echo >&2 "Sorry $0 not available here"
> exit 1
>
> in unimplemented.sh, *without* touching code that calls out to
> scripts that happen to be implemented in Perl.
OK, that is more or less what I proposed elsewhere in the thread. Below
is a cleaned up version of the Makefile bits.
The test script changes should come in a different patch, but they are a
bit more complex. Tests that rely on missing scripts should obviously
just be skipped outright. But there are some test scripts that use perl
for testing tasks (e.g., t4103), and those are not covered by Robin's
patch. Do we want to also skip those? Do we want to place the burden on
authors of the test suite to always check for NO_PERL whenever they use
perl?
The other option would be saying "we support building with NO_PERL, but
not running the test suite".
Thoughts?
-- >8 --
Subject: [PATCH] Makefile: allow building without perl
For systems with a missing or broken perl, it is nicer to
explicitly say "we don't want perl" because:
1. The Makefile knows not to bother with Perl-ish things
like Git.pm.
2. We can print a more user-friendly error message
than "foo is not a git command" or whatever the broken
perl might barf
3. Test scripts that require perl can mark themselves and
such and be skipped
This patch implements parts (1) and (2). The perl/
subdirectory is skipped entirely, gitweb is not built, and
any git commands which rely on perl will print a
human-readable message and exit with an error code.
This patch is based on one from Robin H. Johnson.
Signed-off-by: Jeff King <peff@peff.net>
---
Makefile | 23 +++++++++++++++++++++--
unimplemented.sh | 4 ++++
2 files changed, 25 insertions(+), 2 deletions(-)
create mode 100644 unimplemented.sh
diff --git a/Makefile b/Makefile
index 0675c43..44c856d 100644
--- a/Makefile
+++ b/Makefile
@@ -139,6 +139,8 @@ all::
# Define NO_PERL_MAKEMAKER if you cannot use Makefiles generated by perl's
# MakeMaker (e.g. using ActiveState under Cygwin).
#
+# Define NO_PERL if you do not want Perl scripts or libraries at all.
+#
# Define NO_TCLTK if you do not want Tcl/Tk GUI.
#
# The TCL_PATH variable governs the location of the Tcl interpreter
@@ -335,7 +337,10 @@ BUILT_INS += git-whatchanged$X
ALL_PROGRAMS = $(PROGRAMS) $(SCRIPTS)
# what 'all' will build but not install in gitexecdir
-OTHER_PROGRAMS = git$X gitweb/gitweb.cgi
+OTHER_PROGRAMS = git$X
+ifndef NO_PERL
+OTHER_PROGRAMS += gitweb/gitweb.cgi
+endif
# Set paths to tools early so that they can be used for version tests.
ifndef SHELL_PATH
@@ -1142,7 +1147,9 @@ ifndef NO_TCLTK
$(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) gitexecdir='$(gitexec_instdir_SQ)' all
$(QUIET_SUBDIR0)gitk-git $(QUIET_SUBDIR1) all
endif
+ifndef NO_PERL
$(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' all
+endif
$(QUIET_SUBDIR0)templates $(QUIET_SUBDIR1)
please_set_SHELL_PATH_to_a_more_modern_shell:
@@ -1189,6 +1196,7 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
chmod +x $@+ && \
mv $@+ $@
+ifndef NO_PERL
$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/perl.mak
perl/perl.mak: GIT-CFLAGS perl/Makefile perl/Makefile.PL
@@ -1248,6 +1256,15 @@ git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
$@.sh > $@+ && \
chmod +x $@+ && \
mv $@+ $@
+else # NO_PERL
+$(patsubst %.perl,%,$(SCRIPT_PERL)) git-instaweb: % : unimplemented.sh
+ $(QUIET_GEN)$(RM) $@ $@+ && \
+ sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
+ -e 's|@@REASON@@|NO_PERL=$(NO_PERL)|g' \
+ unimplemented.sh >$@+ && \
+ chmod +x $@+ && \
+ mv $@+ $@
+endif # NO_PERL
configure: configure.ac
$(QUIET_GEN)$(RM) $@ $<+ && \
@@ -1565,9 +1582,11 @@ clean:
$(RM) -r $(GIT_TARNAME) .doc-tmp-dir
$(RM) $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
$(RM) $(htmldocs).tar.gz $(manpages).tar.gz
- $(RM) gitweb/gitweb.cgi
$(MAKE) -C Documentation/ clean
+ifndef NO_PERL
+ $(RM) gitweb/gitweb.cgi
$(MAKE) -C perl clean
+endif
$(MAKE) -C templates/ clean
$(MAKE) -C t/ clean
ifndef NO_TCLTK
diff --git a/unimplemented.sh b/unimplemented.sh
new file mode 100644
index 0000000..5252de4
--- /dev/null
+++ b/unimplemented.sh
@@ -0,0 +1,4 @@
+#!/bin/sh
+
+echo >&2 "fatal: git was built without support for `basename $0` (@@REASON@@)."
+exit 128
--
1.6.2.2.569.g2d4b2
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] NO_PERL support
From: Johannes Sixt @ 2009-04-03 17:54 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: Jeff King, Git Mailing List
In-Reply-To: <20090403132029.GC21153@coredump.intra.peff.net>
On Freitag, 3. April 2009, Jeff King wrote:
> On Fri, Apr 03, 2009 at 12:03:50AM -0700, Robin H. Johnson wrote:
> > +if test -n "$NO_PERL"
> > +then
> > + test_expect_success 'skipping git-svn tests, NO_PERL defined' :
> > + test_done
> > + exit
> > +fi
>
> This probably got copied from an older example, but I think the
> recommended way to skip tests these days is to use 'say' instead of
> test_expect_success (since we have statistics on passing/failing tests
> now).
>
> Also, it may make sense to integrate this with Johannes Sixt's
> test_have_prereq work (which is still in next), but I haven't looked too
> closely at that.
If you base the patch on 'master', you can add this line to test-lib.sh
test -z "$NO_PERL" && test_set_prereq PERL
[But actually, if I read you patch correctly, NO_PERL will be set in
t/Makefile only if one runs 'make test' from the main directory. You should
invent some method to detect missing perl (or that NO_PERL was set) if 'make'
is run directly from t/.]
Now you write the above as
if ! test_have_prereq PERL
then
say 'perl not available - skipping git-svn tests'
test_done
exit
fi
Furthermore, you can skip single tests like this:
> > -test_expect_success \
> > +[ -z "$NO_PERL" ] && test_expect_success \
test_expect_success PERL \
-- Hannes
^ permalink raw reply
* Re: How to merge in different order?
From: Josef Wolf @ 2009-04-03 17:59 UTC (permalink / raw)
To: git
In-Reply-To: <20090403163150.GD8155@coredump.intra.peff.net>
On Fri, Apr 03, 2009 at 12:31:50PM -0400, Jeff King wrote:
[ ... ]
> But what you probably want to do is rewrite the history of your branch
> to re-order the commits.
Yeah, That's exactly what I need. But I guess there's a lot of work ahead:
about 2500 commits are waiting for the sort.
> You can do this with "git rebase -i".
Sounds good
> Like any
> history rewriting, this can cause difficulties for people who you have
> already shared the branch with (because it will replace the commits that
> they already have with 5 _new_ commits that just happen to do more or
> less the same thing).
This is a copy of a svn repository, created with git-svn. So the branch
is shared with other people.
> If you have already shared the branch, you may just want to cherry-pick
> the changes you want (using "git cherry-pick") onto your other branch.
Argh, I was looking for git-cherry, but that does something different ;-)
Thanks for the answer, Jeff!
^ permalink raw reply
* How to init a empty repo for pushing?
From: Changsheng Jiang @ 2009-04-03 18:17 UTC (permalink / raw)
To: git
Hi list,
I have a repository in my laptop, and need to push the repo to a
remote server using ssh protocol.
I know how to init a original repo. But the repo in the server is not
original, the laptop repo is.
Just 'git init' in server, then 'git push server' after 'git remote
add server ...' in laptop gives error.
Thanks,
Changsheng Jiang
^ permalink raw reply
* Re: How to init a empty repo for pushing?
From: Jeff King @ 2009-04-03 18:23 UTC (permalink / raw)
To: Changsheng Jiang; +Cc: git
In-Reply-To: <eafc0afe0904031117rbfd55cft5f40f1b45df1e454@mail.gmail.com>
On Sat, Apr 04, 2009 at 02:17:33AM +0800, Changsheng Jiang wrote:
> Just 'git init' in server, then 'git push server' after 'git remote
> add server ...' in laptop gives error.
It's hard to say without seeing the error message, but I'm assuming it
was along the lines of "No refs in common".
By default, "git push server" will push matching branches (i.e., ones
that both the client and the server have in common). To push a new
branch, you say "git push server $BRANCH", or even just "git push --all
server".
-Peff
^ permalink raw reply
* Re: How to init a empty repo for pushing?
From: Changsheng Jiang @ 2009-04-03 18:27 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090403182312.GA15071@coredump.intra.peff.net>
On Sat, Apr 4, 2009 at 02:23, Jeff King <peff@peff.net> wrote:
> On Sat, Apr 04, 2009 at 02:17:33AM +0800, Changsheng Jiang wrote:
>
>> Just 'git init' in server, then 'git push server' after 'git remote
>> add server ...' in laptop gives error.
>
> It's hard to say without seeing the error message, but I'm assuming it
> was along the lines of "No refs in common".
>
> By default, "git push server" will push matching branches (i.e., ones
> that both the client and the server have in common). To push a new
> branch, you say "git push server $BRANCH", or even just "git push --all
> server".
Thanks, 'git push --all server' works.
>
> -Peff
>
Changsheng Jiang
^ permalink raw reply
* Re: [PATCH] NO_PERL support
From: Jeff King @ 2009-04-03 18:37 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Robin H. Johnson, Git Mailing List
In-Reply-To: <200904031954.57584.j6t@kdbg.org>
On Fri, Apr 03, 2009 at 07:54:57PM +0200, Johannes Sixt wrote:
> If you base the patch on 'master', you can add this line to test-lib.sh
>
> test -z "$NO_PERL" && test_set_prereq PERL
Thanks, I'm working up a patch using this now.
> [But actually, if I read you patch correctly, NO_PERL will be set in
> t/Makefile only if one runs 'make test' from the main directory. You should
> invent some method to detect missing perl (or that NO_PERL was set) if 'make'
> is run directly from t/.]
Yes, it should go into GIT-BUILD-OPTIONS which gets sourced by
test-lib.sh (and then it not only works with "make test" from "t/", but
also with "sh t????-whatever.sh".
-Peff
^ permalink raw reply
* [PATCH 0/4] NO_PERL support
From: Jeff King @ 2009-04-03 19:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin H. Johnson, Git Mailing List
In-Reply-To: <20090403T065545Z@curie.orbis-terrarum.net>
OK, here is a series based on Robin's patch that I think is suitable for
inclusion in mainstream git. The first two are related cleanups, the
third is a rebase of what I sent earlier today, and the fourth covers
the matching tests.
1/4: commit: abort commit if interactive add failed
2/4: tests: remove exit after test_done call
3/4: Makefile: allow building without perl
4/4: tests: skip perl tests if NO_PERL is defined
With these applied, you can build and pass the tests with NO_PERL
defined. _But_ you still can't pass the tests without perl installed at
all, as several of the other tests rely on perl to do text munging in
the tests. I'm not sure it is possible to rewrite them not to use perl;
we ended up with perl in the first place because many versions of
standard tools like sed don't handle NULs very well. So I think the only
option would be to skip those tests, too.
Breaking my perl installation yields these failing tests:
$ cat <<'EOF' >$HOME/local/bin
#!/bin/sh
echo >&2 I am a broken perl.
exit 1
EOF
$ make test NO_PERL=NoThanks
...
$ cd t && grep 'failed [^0]' test-results/*
test-results/t0020-crlf-25091:failed 16
test-results/t1300-repo-config-30265:failed 2
test-results/t3300-funny-names-4931:failed 3
test-results/t4012-diff-binary-22876:failed 1
test-results/t4014-format-patch-23170:failed 14
test-results/t4020-diff-external-25409:failed 2
test-results/t4029-diff-trailing-space-26781:failed 1
test-results/t4030-diff-textconv-26899:failed 5
test-results/t4031-diff-rewrite-binary-26911:failed 1
test-results/t4103-apply-binary-28344:failed 8
test-results/t4116-apply-reverse-29276:failed 7
test-results/t4200-rerere-30898:failed 1
test-results/t5300-pack-object-983:failed 24
test-results/t5303-pack-corruption-resilience-2980:failed 3
test-results/t6002-rev-list-bisect-17175:failed 12
test-results/t6003-rev-list-topo-order-17683:failed 31
test-results/t6011-rev-list-with-bad-commit-19971:failed 3
test-results/t6013-rev-list-reverse-parents-20684:failed 2
test-results/t8001-annotate-11125:failed 10
test-results/t8002-blame-11523:failed 10
^ permalink raw reply
* [PATCH 1/4] commit: abort commit if interactive add failed
From: Jeff King @ 2009-04-03 19:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin H. Johnson, Git Mailing List
In-Reply-To: <20090403192700.GA14965@coredump.intra.peff.net>
Previously we ignored the result of calling add_interactive,
which meant that if an error occurred we simply committed
whatever happened to be in the index.
Signed-off-by: Jeff King <peff@peff.net>
---
Just a fix I noticed while looking at t7501.
builtin-commit.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 46e649c..81371b1 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -224,7 +224,8 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
const char **pathspec = NULL;
if (interactive) {
- interactive_add(argc, argv, prefix);
+ if (interactive_add(argc, argv, prefix) != 0)
+ die("interactive add failed");
if (read_cache_preload(NULL) < 0)
die("index file corrupt");
commit_style = COMMIT_AS_IS;
--
1.6.2.2.569.g2d4b2
^ permalink raw reply related
* [PATCH 2/4] tests: remove exit after test_done call
From: Jeff King @ 2009-04-03 19:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin H. Johnson, Git Mailing List
In-Reply-To: <20090403192700.GA14965@coredump.intra.peff.net>
test_done always exits, so this line is never executed.
Signed-off-by: Jeff King <peff@peff.net>
---
A cleanup I noticed while adding more test skipping. Technically these
lines were not hurting anything, but I think it prevents a reader from
wondering why some test_done instances are followed by exit and some are
not.
And just look at that diffstat line count. It _must_ be an improvement!
t/lib-git-svn.sh | 4 ----
t/lib-httpd.sh | 3 ---
t/t4004-diff-rename-symlink.sh | 1 -
t/t4011-diff-symlink.sh | 1 -
t/t4023-diff-rename-typechange.sh | 1 -
t/t4114-apply-typechange.sh | 1 -
t/t4115-apply-symlink.sh | 1 -
t/t4122-apply-symlink-inside.sh | 1 -
t/t5503-tagfollow.sh | 1 -
t/t5522-pull-symlink.sh | 1 -
t/t5540-http-push.sh | 1 -
t/t7005-editor.sh | 1 -
t/t9200-git-cvsexportcommit.sh | 1 -
t/t9400-git-cvsserver-server.sh | 2 --
t/t9401-git-cvsserver-crlf.sh | 2 --
t/t9500-gitweb-standalone-no-errors.sh | 1 -
t/t9600-cvsimport.sh | 3 ---
17 files changed, 0 insertions(+), 26 deletions(-)
diff --git a/t/lib-git-svn.sh b/t/lib-git-svn.sh
index de384e6..cdd7ccd 100644
--- a/t/lib-git-svn.sh
+++ b/t/lib-git-svn.sh
@@ -7,7 +7,6 @@ if test -n "$NO_SVN_TESTS"
then
say 'skipping git svn tests, NO_SVN_TESTS defined'
test_done
- exit
fi
GIT_DIR=$PWD/.git
@@ -19,7 +18,6 @@ if test $? -ne 1
then
say 'skipping git svn tests, svn not found'
test_done
- exit
fi
svnrepo=$PWD/svnrepo
@@ -43,7 +41,6 @@ then
fi
say "$err"
test_done
- exit
fi
rawsvnrepo="$svnrepo"
@@ -144,7 +141,6 @@ require_svnserve () {
then
say 'skipping svnserve test. (set $SVNSERVE_PORT to enable)'
test_done
- exit
fi
}
diff --git a/t/lib-httpd.sh b/t/lib-httpd.sh
index 589aaf8..cde659d 100644
--- a/t/lib-httpd.sh
+++ b/t/lib-httpd.sh
@@ -8,7 +8,6 @@ then
say "skipping test, network testing disabled by default"
say "(define GIT_TEST_HTTPD to enable)"
test_done
- exit
fi
HTTPD_PARA=""
@@ -36,7 +35,6 @@ if ! test -x "$LIB_HTTPD_PATH"
then
say "skipping test, no web server found at '$LIB_HTTPD_PATH'"
test_done
- exit
fi
HTTPD_VERSION=`$LIB_HTTPD_PATH -v | \
@@ -50,7 +48,6 @@ then
then
say "skipping test, at least Apache version 2 is required"
test_done
- exit
fi
LIB_HTTPD_MODULE_PATH="$DEFAULT_HTTPD_MODULE_PATH"
diff --git a/t/t4004-diff-rename-symlink.sh b/t/t4004-diff-rename-symlink.sh
index 3db7444..a4da119 100755
--- a/t/t4004-diff-rename-symlink.sh
+++ b/t/t4004-diff-rename-symlink.sh
@@ -16,7 +16,6 @@ if ! test_have_prereq SYMLINKS
then
say 'Symbolic links not supported, skipping tests.'
test_done
- exit
fi
test_expect_success \
diff --git a/t/t4011-diff-symlink.sh b/t/t4011-diff-symlink.sh
index 3a81309..d7e327c 100755
--- a/t/t4011-diff-symlink.sh
+++ b/t/t4011-diff-symlink.sh
@@ -13,7 +13,6 @@ if ! test_have_prereq SYMLINKS
then
say 'Symbolic links not supported, skipping tests.'
test_done
- exit
fi
cat > expected << EOF
diff --git a/t/t4023-diff-rename-typechange.sh b/t/t4023-diff-rename-typechange.sh
index 5099862..9bdf659 100755
--- a/t/t4023-diff-rename-typechange.sh
+++ b/t/t4023-diff-rename-typechange.sh
@@ -8,7 +8,6 @@ if ! test_have_prereq SYMLINKS
then
say 'Symbolic links not supported, skipping tests.'
test_done
- exit
fi
test_expect_success setup '
diff --git a/t/t4114-apply-typechange.sh b/t/t4114-apply-typechange.sh
index 7dc35de..99ec13d 100755
--- a/t/t4114-apply-typechange.sh
+++ b/t/t4114-apply-typechange.sh
@@ -13,7 +13,6 @@ if ! test_have_prereq SYMLINKS
then
say 'Symbolic links not supported, skipping tests.'
test_done
- exit
fi
test_expect_success 'setup repository and commits' '
diff --git a/t/t4115-apply-symlink.sh b/t/t4115-apply-symlink.sh
index 1a3aea3..b852e58 100755
--- a/t/t4115-apply-symlink.sh
+++ b/t/t4115-apply-symlink.sh
@@ -13,7 +13,6 @@ if ! test_have_prereq SYMLINKS
then
say 'Symbolic links not supported, skipping tests.'
test_done
- exit
fi
test_expect_success setup '
diff --git a/t/t4122-apply-symlink-inside.sh b/t/t4122-apply-symlink-inside.sh
index 8aad20b..0d3c1d5 100755
--- a/t/t4122-apply-symlink-inside.sh
+++ b/t/t4122-apply-symlink-inside.sh
@@ -7,7 +7,6 @@ if ! test_have_prereq SYMLINKS
then
say 'Symbolic links not supported, skipping tests.'
test_done
- exit
fi
lecho () {
diff --git a/t/t5503-tagfollow.sh b/t/t5503-tagfollow.sh
index e75ccbc..d5db75d 100755
--- a/t/t5503-tagfollow.sh
+++ b/t/t5503-tagfollow.sh
@@ -8,7 +8,6 @@ case $(uname -s) in
*MINGW*)
say "GIT_DEBUG_SEND_PACK not supported - skipping tests"
test_done
- exit
esac
# End state of the repository:
diff --git a/t/t5522-pull-symlink.sh b/t/t5522-pull-symlink.sh
index d887eb6..86bbd7d 100755
--- a/t/t5522-pull-symlink.sh
+++ b/t/t5522-pull-symlink.sh
@@ -8,7 +8,6 @@ if ! test_have_prereq SYMLINKS
then
say 'Symbolic links not supported, skipping tests.'
test_done
- exit
fi
# The scenario we are building:
diff --git a/t/t5540-http-push.sh b/t/t5540-http-push.sh
index c46592f..5fe479e 100755
--- a/t/t5540-http-push.sh
+++ b/t/t5540-http-push.sh
@@ -17,7 +17,6 @@ if git http-push > /dev/null 2>&1 || [ $? -eq 128 ]
then
say "skipping test, USE_CURL_MULTI is not defined"
test_done
- exit
fi
. "$TEST_DIRECTORY"/lib-httpd.sh
diff --git a/t/t7005-editor.sh b/t/t7005-editor.sh
index e83bc8f..b647957 100755
--- a/t/t7005-editor.sh
+++ b/t/t7005-editor.sh
@@ -92,7 +92,6 @@ if ! echo 'echo space > "$1"' > "e space.sh"
then
say "Skipping; FS does not support spaces in filenames"
test_done
- exit
fi
test_expect_success 'editor with a space' '
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
index 995f607..3665692 100755
--- a/t/t9200-git-cvsexportcommit.sh
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -11,7 +11,6 @@ if test $? -ne 1
then
say 'skipping git cvsexportcommit tests, cvs not found'
test_done
- exit
fi
CVSROOT=$(pwd)/cvsroot
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index 466240c..39185db 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -15,12 +15,10 @@ if test $? -ne 1
then
say 'skipping git-cvsserver tests, cvs not found'
test_done
- exit
fi
perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
say 'skipping git-cvsserver tests, Perl SQLite interface unavailable'
test_done
- exit
}
unset GIT_DIR GIT_CONFIG
diff --git a/t/t9401-git-cvsserver-crlf.sh b/t/t9401-git-cvsserver-crlf.sh
index 8882230..12e0e50 100755
--- a/t/t9401-git-cvsserver-crlf.sh
+++ b/t/t9401-git-cvsserver-crlf.sh
@@ -51,12 +51,10 @@ if test $? -ne 1
then
say 'skipping git-cvsserver tests, cvs not found'
test_done
- exit
fi
perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
say 'skipping git-cvsserver tests, Perl SQLite interface unavailable'
test_done
- exit
}
unset GIT_DIR GIT_CONFIG
diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh
index 9ec5030..0bd332c 100755
--- a/t/t9500-gitweb-standalone-no-errors.sh
+++ b/t/t9500-gitweb-standalone-no-errors.sh
@@ -68,7 +68,6 @@ gitweb_run () {
perl -MEncode -e 'decode_utf8("", Encode::FB_CROAK)' >/dev/null 2>&1 || {
say 'skipping gitweb tests, perl version is too old'
test_done
- exit
}
gitweb_init
diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh
index d2379e7..33eb519 100755
--- a/t/t9600-cvsimport.sh
+++ b/t/t9600-cvsimport.sh
@@ -14,7 +14,6 @@ if ! type cvs >/dev/null 2>&1
then
say 'skipping cvsimport tests, cvs not found'
test_done
- exit
fi
cvsps_version=`cvsps -h 2>&1 | sed -ne 's/cvsps version //p'`
@@ -24,12 +23,10 @@ case "$cvsps_version" in
'')
say 'skipping cvsimport tests, cvsps not found'
test_done
- exit
;;
*)
say 'skipping cvsimport tests, unsupported cvsps version'
test_done
- exit
;;
esac
--
1.6.2.2.569.g2d4b2
^ permalink raw reply related
* [PATCH 3/4] Makefile: allow building without perl
From: Jeff King @ 2009-04-03 19:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin H. Johnson, Git Mailing List
In-Reply-To: <20090403192700.GA14965@coredump.intra.peff.net>
For systems with a missing or broken perl, it is nicer to
explicitly say "we don't want perl" because:
1. The Makefile knows not to bother with Perl-ish things
like Git.pm.
2. We can print a more user-friendly error message
than "foo is not a git command" or whatever the broken
perl might barf
3. Test scripts that require perl can mark themselves and
such and be skipped
This patch implements parts (1) and (2). The perl/
subdirectory is skipped entirely, gitweb is not built, and
any git commands which rely on perl will print a
human-readable message and exit with an error code.
This patch is based on one from Robin H. Johnson.
Signed-off-by: Jeff King <peff@peff.net>
---
This is a rebase of what I sent earlier (the original was based on
1.6.2.1).
Makefile | 23 +++++++++++++++++++++--
unimplemented.sh | 4 ++++
2 files changed, 25 insertions(+), 2 deletions(-)
create mode 100644 unimplemented.sh
diff --git a/Makefile b/Makefile
index 7867eac..d7b0837 100644
--- a/Makefile
+++ b/Makefile
@@ -145,6 +145,8 @@ all::
# Define NO_PERL_MAKEMAKER if you cannot use Makefiles generated by perl's
# MakeMaker (e.g. using ActiveState under Cygwin).
#
+# Define NO_PERL if you do not want Perl scripts or libraries at all.
+#
# Define NO_TCLTK if you do not want Tcl/Tk GUI.
#
# The TCL_PATH variable governs the location of the Tcl interpreter
@@ -353,7 +355,10 @@ BUILT_INS += git-whatchanged$X
ALL_PROGRAMS = $(PROGRAMS) $(SCRIPTS)
# what 'all' will build but not install in gitexecdir
-OTHER_PROGRAMS = git$X gitweb/gitweb.cgi
+OTHER_PROGRAMS = git$X
+ifndef NO_PERL
+OTHER_PROGRAMS += gitweb/gitweb.cgi
+endif
# Set paths to tools early so that they can be used for version tests.
ifndef SHELL_PATH
@@ -1178,7 +1183,9 @@ ifndef NO_TCLTK
$(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) gitexecdir='$(gitexec_instdir_SQ)' all
$(QUIET_SUBDIR0)gitk-git $(QUIET_SUBDIR1) all
endif
+ifndef NO_PERL
$(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' all
+endif
$(QUIET_SUBDIR0)templates $(QUIET_SUBDIR1)
please_set_SHELL_PATH_to_a_more_modern_shell:
@@ -1225,6 +1232,7 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
chmod +x $@+ && \
mv $@+ $@
+ifndef NO_PERL
$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/perl.mak
perl/perl.mak: GIT-CFLAGS perl/Makefile perl/Makefile.PL
@@ -1284,6 +1292,15 @@ git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
$@.sh > $@+ && \
chmod +x $@+ && \
mv $@+ $@
+else # NO_PERL
+$(patsubst %.perl,%,$(SCRIPT_PERL)) git-instaweb: % : unimplemented.sh
+ $(QUIET_GEN)$(RM) $@ $@+ && \
+ sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
+ -e 's|@@REASON@@|NO_PERL=$(NO_PERL)|g' \
+ unimplemented.sh >$@+ && \
+ chmod +x $@+ && \
+ mv $@+ $@
+endif # NO_PERL
configure: configure.ac
$(QUIET_GEN)$(RM) $@ $<+ && \
@@ -1602,9 +1619,11 @@ clean:
$(RM) -r $(GIT_TARNAME) .doc-tmp-dir
$(RM) $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
$(RM) $(htmldocs).tar.gz $(manpages).tar.gz
- $(RM) gitweb/gitweb.cgi
$(MAKE) -C Documentation/ clean
+ifndef NO_PERL
+ $(RM) gitweb/gitweb.cgi
$(MAKE) -C perl clean
+endif
$(MAKE) -C templates/ clean
$(MAKE) -C t/ clean
ifndef NO_TCLTK
diff --git a/unimplemented.sh b/unimplemented.sh
new file mode 100644
index 0000000..5252de4
--- /dev/null
+++ b/unimplemented.sh
@@ -0,0 +1,4 @@
+#!/bin/sh
+
+echo >&2 "fatal: git was built without support for `basename $0` (@@REASON@@)."
+exit 128
--
1.6.2.2.569.g2d4b2
^ permalink raw reply related
* [PATCH 4/4] tests: skip perl tests if NO_PERL is defined
From: Jeff King @ 2009-04-03 19:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin H. Johnson, Git Mailing List
In-Reply-To: <20090403192700.GA14965@coredump.intra.peff.net>
These scripts all test git programs that are written in
perl, and thus obviously won't work if NO_PERL is defined.
We pass NO_PERL to the scripts from the building Makefile
via the GIT-BUILD-OPTIONS file.
Signed-off-by: Jeff King <peff@peff.net>
---
This touches every test that Robin's patch touched except for
t5505-remote. There is no need to skip those tests, as these days
"git remote" is a builtin.
Makefile | 1 +
t/lib-git-svn.sh | 4 ++++
t/t3701-add-interactive.sh | 5 +++++
t/t7501-commit.sh | 4 ++--
t/t9001-send-email.sh | 5 +++++
t/t9200-git-cvsexportcommit.sh | 5 +++++
t/t9400-git-cvsserver-server.sh | 4 ++++
t/t9500-gitweb-standalone-no-errors.sh | 5 +++++
t/t9600-cvsimport.sh | 5 +++++
t/t9700-perl-git.sh | 5 +++++
t/test-lib.sh | 2 ++
11 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index d7b0837..584a757 100644
--- a/Makefile
+++ b/Makefile
@@ -1417,6 +1417,7 @@ GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
@echo SHELL_PATH=\''$(subst ','\'',$(SHELL_PATH_SQ))'\' >$@
@echo TAR=\''$(subst ','\'',$(subst ','\'',$(TAR)))'\' >>$@
@echo NO_CURL=\''$(subst ','\'',$(subst ','\'',$(NO_CURL)))'\' >>$@
+ @echo NO_PERL=\''$(subst ','\'',$(subst ','\'',$(NO_PERL)))'\' >>$@
### Detect Tck/Tk interpreter path changes
ifndef NO_TCLTK
diff --git a/t/lib-git-svn.sh b/t/lib-git-svn.sh
index cdd7ccd..773d47c 100644
--- a/t/lib-git-svn.sh
+++ b/t/lib-git-svn.sh
@@ -8,6 +8,10 @@ then
say 'skipping git svn tests, NO_SVN_TESTS defined'
test_done
fi
+if ! test_have_prereq PERL; then
+ say 'skipping git svn tests, perl not available'
+ test_done
+fi
GIT_DIR=$PWD/.git
GIT_SVN_DIR=$GIT_DIR/svn/git-svn
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index fe01783..dfc6560 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -3,6 +3,11 @@
test_description='add -i basic tests'
. ./test-lib.sh
+if ! test_have_prereq PERL; then
+ say 'skipping git add -i tests, perl not available'
+ test_done
+fi
+
test_expect_success 'setup (initial)' '
echo content >file &&
git add file &&
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index b4e2b4d..e2ef532 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -38,7 +38,7 @@ test_expect_success \
"echo King of the bongo >file &&
test_must_fail git commit -m foo -a file"
-test_expect_success \
+test_expect_success PERL \
"using paths with --interactive" \
"echo bong-o-bong >file &&
! (echo 7 | git commit -m foo --interactive file)"
@@ -119,7 +119,7 @@ test_expect_success \
"echo 'gak' >file && \
git commit -m 'author' --author 'Rubber Duck <rduck@convoy.org>' -a"
-test_expect_success \
+test_expect_success PERL \
"interactive add" \
"echo 7 | git commit --interactive | grep 'What now'"
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 192b97b..4281ce2 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -3,6 +3,11 @@
test_description='git send-email'
. ./test-lib.sh
+if ! test_have_prereq PERL; then
+ say 'skipping git send-email tests, perl not available'
+ test_done
+fi
+
PROG='git send-email'
test_expect_success \
'prepare reference tree' \
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
index 3665692..56b7c06 100755
--- a/t/t9200-git-cvsexportcommit.sh
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -6,6 +6,11 @@ test_description='Test export of commits to CVS'
. ./test-lib.sh
+if ! test_have_prereq PERL; then
+ say 'skipping git cvsexportcommit tests, perl not available'
+ test_done
+fi
+
cvs >/dev/null 2>&1
if test $? -ne 1
then
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index 39185db..64f947d 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -10,6 +10,10 @@ cvs CLI client via git-cvsserver server'
. ./test-lib.sh
+if ! test_have_prereq PERL; then
+ say 'skipping git cvsserver tests, perl not available'
+ test_done
+fi
cvs >/dev/null 2>&1
if test $? -ne 1
then
diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh
index 0bd332c..f4210fb 100755
--- a/t/t9500-gitweb-standalone-no-errors.sh
+++ b/t/t9500-gitweb-standalone-no-errors.sh
@@ -65,6 +65,11 @@ gitweb_run () {
. ./test-lib.sh
+if ! test_have_prereq PERL; then
+ say 'skipping gitweb tests, perl not available'
+ test_done
+fi
+
perl -MEncode -e 'decode_utf8("", Encode::FB_CROAK)' >/dev/null 2>&1 || {
say 'skipping gitweb tests, perl version is too old'
test_done
diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh
index 33eb519..4322a0c 100755
--- a/t/t9600-cvsimport.sh
+++ b/t/t9600-cvsimport.sh
@@ -3,6 +3,11 @@
test_description='git cvsimport basic tests'
. ./test-lib.sh
+if ! test_have_prereq PERL; then
+ say 'skipping git cvsimport tests, perl not available'
+ test_done
+fi
+
CVSROOT=$(pwd)/cvsroot
export CVSROOT
unset CVS_SERVER
diff --git a/t/t9700-perl-git.sh b/t/t9700-perl-git.sh
index 4a501c6..b4ca244 100755
--- a/t/t9700-perl-git.sh
+++ b/t/t9700-perl-git.sh
@@ -6,6 +6,11 @@
test_description='perl interface (Git.pm)'
. ./test-lib.sh
+if ! test_have_prereq PERL; then
+ say 'skipping perl interface tests, perl not available'
+ test_done
+fi
+
perl -MTest::More -e 0 2>/dev/null || {
say "Perl Test::More unavailable, skipping test"
test_done
diff --git a/t/test-lib.sh b/t/test-lib.sh
index b050196..4bd986f 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -698,6 +698,8 @@ case $(uname -s) in
;;
esac
+test -z "$NO_PERL" && test_set_prereq PERL
+
# test whether the filesystem supports symbolic links
ln -s x y 2>/dev/null && test -h y 2>/dev/null && test_set_prereq SYMLINKS
rm -f y
--
1.6.2.2.569.g2d4b2
^ permalink raw reply related
* Re: [PATCH] NO_PERL support
From: Junio C Hamano @ 2009-04-03 20:20 UTC (permalink / raw)
To: Jeff King; +Cc: Robin H. Johnson, Git Mailing List
In-Reply-To: <20090403171514.GA11112@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Do we want to also skip those? Do we want to place the burden on
> authors of the test suite to always check for NO_PERL whenever they use
> perl?
>
> The other option would be saying "we support building with NO_PERL, but
> not running the test suite".
>
> Thoughts?
Yes, no, and probably not.
Let me clarify the last "probably not" first, because it will be the
reason behind the first "Yes".
Saying "We support building but not testing" is like saying "we don't
support it", and honestly, we'd be better off leaving this patch out of
tree if that is what we are going to do. Even though I am not personally
very enthused about NO_PERL, the Makefile patch itself does not look too
bad, and if we can finish this with very limited injury to the overall
codebase, I wouldn't mind carrying the option in-tree.
Side note: by the way, what did you or Robin's patch do to
Documentation/cmd-list.perl and other bits of build infrastructure
that rely on Perl?
To solve the second "no" cleanly, I am wondering if we can do something
clever by defining $PERL to be used in t/t*.sh scripts. They should be
using configured PERL_PATH for running the tests _anyway_, even though I
see many hits from "git grep -e perl t/" right now.
But even if there isn't a room for doing something clever there, I think
the test prerequisite framework J6t did recently should be usable without
cluttering the test suite too much. That forces test authors to be aware
of NO_PERL, which is slightly yucky, but if it cannot be helped, I think
we can survive. We do the same for UTF8 and SYMLINKS already.
^ permalink raw reply
* Re: [PATCH] NO_PERL support
From: Jeff King @ 2009-04-03 20:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin H. Johnson, Git Mailing List
In-Reply-To: <7vocvd8p6s.fsf@gitster.siamese.dyndns.org>
On Fri, Apr 03, 2009 at 01:20:11PM -0700, Junio C Hamano wrote:
> Saying "We support building but not testing" is like saying "we don't
> support it", and honestly, we'd be better off leaving this patch out of
> tree if that is what we are going to do. Even though I am not personally
Well, there are actually multiple levels that are worth considering. The
tasks you might want to accomplish are:
1. Build the programs
2. Run the test suite
3. Run the programs (excepting the perl ones, of course); note
that being able to build is not necessarily a prerequisite,
as you might receive git as a binary package.
4. Build the documentation
5. View the documentation
Right now, (1), (2), and (4) are broken without perl. (5) works fine
because it doesn't involve perl at all. (3) works the same, except you
get error messages like "not a git command".
I can think of three situations which are helped by my patch series:
- You are on a system with no perl. You don't care about running the
test suite, but you do want to use basic git. You can now build and
run, with the except of the perl scripts.
- You are on a system with an old or inferior perl. For example, my
Solaris test box has perl 5.005, and I know Alex has complained
about Activestate perl on more than one occasion. The inferior perl
is generally enough to run the little snippets in the test suite and
the Documentation Makefile. So you can now build and run git (minus
the perl bits) and the documentation (in theory -- you don't have
perl but you _do_ have working asciidoc and xmlto?), and you can run
the test suite without having to manually skip a bunch of tests
(which is what I do now).
- You are a package builder distributing binary packages. You have
perl, but you want to build a noperl variant. Perl works for
building the package, but you want the _result_ not to use perl. The
test scripts, of course, must also respect NO_PERL since you have
built placeholder scripts instead of the real thing.
> very enthused about NO_PERL, the Makefile patch itself does not look too
> bad, and if we can finish this with very limited injury to the overall
> codebase, I wouldn't mind carrying the option in-tree.
I don't think it is. See my 3/4.
> Side note: by the way, what did you or Robin's patch do to
> Documentation/cmd-list.perl and other bits of build infrastructure
> that rely on Perl?
Neither patch does anything. AFAIK, Documentation/Makefile uses perl,
but nothing else does (aside from the test scripts previously
mentioned).
> To solve the second "no" cleanly, I am wondering if we can do something
> clever by defining $PERL to be used in t/t*.sh scripts. They should be
> using configured PERL_PATH for running the tests _anyway_, even though I
> see many hits from "git grep -e perl t/" right now.
We can redefine them to use $PERL_PATH (which I agree should be done
anyway), but intercepting there is probably too late. You will be in the
middle of a test, and want to say "Oh wait, I was supposed to skip this
test." Certainly possible, but I think it might make the test code
pretty ugly.
Aside: I think the reason that the lack of PERL_PATH hasn't been a
problem is that people are generally not picking a _different_ perl,
but rather need the whole path to go on the #! line. So the full path
and "whatever is in my PATH" tend to be the same thing.
> But even if there isn't a room for doing something clever there, I think
> the test prerequisite framework J6t did recently should be usable without
> cluttering the test suite too much. That forces test authors to be aware
> of NO_PERL, which is slightly yucky, but if it cannot be helped, I think
> we can survive. We do the same for UTF8 and SYMLINKS already.
See my 4/4, which uses J6t's framework to do the first part (disabling
tests for scripts which we didn't actually build).
A 5/4 might be "disable uses of perl in tests when NO_PERL is set". And
that would be much more invasive. In my scenarios above, it buys the "I
don't have perl at all" people the ability to run a subset of the test
suite (but unlike 4/4, it is skipping tests that are actually useful and
important, but just happen to rely on perl for their infrastructure --
4/4 is by definition skipping tests that have no meaning).
I don't have any Gentoo boxen, but my understanding is that pretty much
everything is built from source. So the "you can make binary packages"
fix doesn't help them that much. OTOH, Robin's current patch doesn't
help that either, so I can only assume they're not really running the
test suite on perl-less systems. And I don't see a reason why upstream
git can't do part of the work (my series), and the Gentoo build can't do
the rest (setting GIT_SKIP_TESTS as appropriate).
-Peff
^ permalink raw reply
* Re: [msysGit] Re: [PATCH] Add custom memory allocator to MinGW and MacOS builds
From: Pat Thoyts @ 2009-04-03 21:12 UTC (permalink / raw)
To: marius; +Cc: git, msysgit
In-Reply-To: <49D61B35.8060508@trolltech.com>
2009/4/3 Marius Storm-Olsen <marius@trolltech.com>:
>
> Marius Storm-Olsen said the following on 03.04.2009 15:52:
>> The standard allocator on Windows is pretty bad prior
>> to Windows Vista, and nedmalloc is better than the
>> modified dlmalloc provided with newer versions of the
>> MinGW libc.
>
> Actually, it just struck me that it's probably the synchronization
> primitives which are better on Vista than XP, and not the memory
> manager? (Since mingw 4.3.3-tdm on XP and Vista most likely use the
> same dlmalloc fork?) ^shrug^
>
> Anyways, not that I haven't tried to 'tune' nedmalloc in any way, just
> ensured that it compiles with the different MinGWs which I
> benchmarked. So, if anyone feels like it, maybe we can squeeze more
> performance out of it by tweaking it.
The difference on Windows Vista is that the low fragmentation heap is
the default memory allocator. On Windows XP you need to enable it
specifically for an application. So a possible alternative to this is
just to enable the low fragmentation heap. (done via GetProcessHeaps
and HeapSetInformation Win32 API calls).
Pat Thoyts
^ permalink raw reply
* GPG signing for git commit?
From: Chow Loong Jin @ 2009-04-03 21:25 UTC (permalink / raw)
To: git
[-- Attachment #1.1: Type: text/plain, Size: 540 bytes --]
Hi,
It crossed my mind that currently git commits cannot actually be
verified to be authentic, due to the fact that I can just set my
identity to be someone else, and then commit under their name. During
discussion on #git, Ilari, context and I figured that it would be a good
idea to get GPG signing on git commits, considering that git-tag already
has GPG signing support.
Attached is the transcript of the log, with some irrelevant bits chopped
out. Log is dated Sat, April 4, and timezone GMT +0800.
--
Chow Loong Jin
[-- Attachment #1.2: git-commit-sign.log --]
[-- Type: text/x-log, Size: 8998 bytes --]
04:35 <hyperair> hmm i've always wondered... is it possible to create commits under someone else's name and then push it to a git server? if it is, how does one prevent that from happening?
04:35 <hyperair> s/git server/git repo/
04:36 <Ilari> hyperair: Sure it is.
04:36 <wereHamster> hyperair: GIT_COMMITTER_NAME="Someone Else" git commit
04:36 <Ilari> UUncia: It has capability to transfer commits between repositories. Pushing (transfer to another repository), Fetching (transfer from another repository, clone/pull are built on top) and sneakernet commit transport are all supported.
04:36 <hyperair> Ilari, wereHamster: yeah i thought so, but how do you prevent someone from pushing to a git repo under your name?
04:36 <wereHamster> hyperair: you'd have to have hooks on the server side that check the commiter name
04:36 <hyperair> ah i see
04:37 <Ilari> hyperair: Then there are situations where one legimately needs to push commit with some oddball committer name.
04:37 <wereHamster> hyperair: also note that git distinguishes between committer and author
04:37 <hyperair> wereHamster: committer and author?
04:38 <hyperair> wereHamster: what's the difference?
04:38 <wereHamster> hyperair: author is the person who wrote the patch, committer is the person who created the commit
04:38 <wereHamster> so if someone sends you a patch, he/she is the author but you are the committer
04:38 <hyperair> wereHamster: how does git tell the difference?
04:39 <hyperair> wereHamster: also, supposing you weren't working by passing patches around, but rather by pushing to a main project repository, what's to stop one committer from committing under another person's name and shoving all the blame onto him?
04:39 <context> the authors are like physics students
04:39 <hyperair> or her?
04:39 <context> and the commiters are rocket scientests
04:40 <wereHamster> I think by looking at the patch headers (assuming it's sent in mbox format)
04:40 <context> hyperair: nothing.
04:40 <hyperair> context: bit insecure don't you think?
04:40 <context> hyperair: there is no way to stop it. you gave them commit access, you trust them enough
04:41 <wereHamster> there is a way to stop it: don't give them committ access ;)
04:41 <context> werehamster: ;)
04:41 <hyperair> wereHamster: you mean push access =p
04:41 <Ilari> hyperair: There are cases like: I work on some feature. I complete it and send pull request to somebody who has push privs to main repo. They pull it and since its up to date, it results fast forward. Then they push it. Again, its up to date so push succeeds. Now you have wound up with situation where topmost commit claims (correctly) that I committed it.
04:41 <context> hyperair: unless you have a propsel on how to stop it
04:42 <Circuitsoft> There isn't really a way to stop it.
04:42 <Ilari> hyperair: You could use hooks to keep logs about who pushed what.
04:42 <hyperair> i see
04:42 <Circuitsoft> Even if there were, there's nothing preventing someone else from setting their identity to you.
04:42 <context> ilari: that still doesnt work.
04:42 <context> ilari: say i pull from you, merge my changes with yours, then merge into master and push to repo
04:43 <context> how do you track the branch i pulled form you is really from you.
04:43 <hyperair> how about gpg signing every commit =p
04:43 <Ilari> context: Both "merges" are fast forwards by assumption there.
04:43 <hyperair> just like how tags can be signed, how about signing them commits
04:43 <context> hyperair: that would work.
04:43 <context> ilari: no i mean merge as in merge.
04:43 <Ilari> hyperair: Its just impractical with current tools.
04:44 <hyperair> Ilari: yeah it's impractical, but if you git git-commit signing capabilities similar to taht of git-tag's i'm sure it would work
04:44 <hyperair> Ilari: and become practical.
04:44 <Ilari> context: Unless you explicitly ask, merge when presented with situation where one of branches is in future of another will make fast forward without any new commits.
04:45 <Ilari> hyperair: There are even hacks that authenticate pushing to git:// by using signed tags.
04:46 <hyperair> Ilari: what hacks are those?
04:46 <Ilari> hyperair: They essentially implement push authentication on top of git://
04:46 <Ilari> hyperair: Not very helpful, because ssh usually does it better.
04:46 <hyperair> yeah i thought so
04:47 <Ilari> hyperair: And as tip: If you want to keep logs, current version of gitosis (last I checked) can not be used in such applications without modification.
04:48 <hyperair> Ilari: what's gitosis?
04:48 <Ilari> hyperair: Software that makes admining repo permissions in group settings easier.
04:48 <hyperair> hmm interesting
04:49 <Dashkal> Sometimes I wish I could annotate a branch. Leave a comment on the branch itself that explains why I made it...
04:49 <Ilari> hyperair: Usually very good. But its lack of exported user identity (unless you can hack it in) is absolute showstopper if you need to keep push logs.
04:49 <hyperair> hmm
04:50 <Ilari> hyperair: But its one line change AFAICS...
04:50 <hyperair> interesting
04:50 <hyperair> Dashkal: self-explanatory names ftw.
04:51 <context> ilari: yes i know
04:51 <context> <-- not new to git
04:59 <context> hyperair: only way to trust a commit would be gpg signatures
04:59 <Dashkal> Ilari: oh? Might have to hunt through git.git for it
04:59 <Ilari> Dashkal: pu has it.
04:59 <Dashkal> nifty, danke
04:59 <context> but i dont think you can gpg sign all commits can you
04:59 <context> not to mention typing in that passwd every commit would SUCK !
04:59 <hyperair> context: yes of course, but git commit doesn't have gpg support.
04:59 <Ilari> Dashkal: Next doesn't. But beware that pu begins to be actually unstable.
04:59 <hyperair> context: ever heard of a gpg agent?
05:00 <context> hyperair: yes. firegpg uses it so i dont have to type it in for every email i send from gmail
05:00 <Dashkal> Ilari: Yeah, I'm kind of afraid of pu as a whole, but if I can find the relivant commits I can bring just that in
05:00 <context> gmail + gpg = win
05:00 <hyperair> i use evolution.
05:00 <context> hyperair: another ewe.
05:00 <context> ;)
05:00 * hyperair wonders what ewe is
05:01 <context> 'icky' growse
05:01 <Ilari> hyperair: Gpg signing doesn't really work if you have external contributors that can request pull unless you force non-ff merge somewhere.
05:01 <hyperair> i don't think it comes with a trailing e
05:01 <context> ilari: eh?
05:01 <context> hyperair: ill have to update my dictionary
05:01 <hyperair> Ilari: the main point is that you make your commits be verifiable, so that nobody can pretend to commit as you.
05:02 <context> hyperair: use svn, ;)
05:02 * hyperair barfs on context
05:02 <Circuitsoft> context: Blasphemer!
05:02 <Ilari> hyperair: Well, if you need identifying of main contributors only.
05:02 * context hides
05:02 <Ilari> hyperair: So no one spoofs them. But it doesn't protect others.
05:02 <context> ilari: actually it wouldnt be too hard. if commit's could be sign
05:02 <hyperair> Ilari: yeah true.
05:03 <context> trusted users could add their finger print to like a ~/.gitfinger file
05:03 <context> people WOULD notice if that gets changed
05:03 <context> and you could have like a git fetch-gpg-keys
05:03 <hyperair> hahah
05:03 <hyperair> i think we should file that as a feature request =p
05:03 <hyperair> if tags can be signed, why not commits? =p
05:04 <Ilari> hyperair: Both even have similar structure. Header fields plus freeform text section.
05:04 <Ilari> hyperair: The text section is even fully 8-bit clean.
05:04 <hyperair> awesome. so let's have it signed =p
05:05 <Ilari> hyperair: Since it starts immediately after first 0A0Ah sequence in object and continues to end of object. And objects need to be 8-bit clean to store binary files in blobs.
05:05 <context> hyperair: then you need to worry about an author signature, AND commiters signature
05:05 <context> and diff's might be even more funky
05:06 <context> but it would be an awesome feature
05:06 <hyperair> context: diffs can have headers and footers. so a clearsign would be fine
05:06 <Ilari> If you care only about protecting main authors, committer signature is enough.
05:06 <Circuitsoft> What if gpg on commit was only used when the --signoff option was selected?
05:07 <Ilari> It also has simplifying factor that signing headers plus rest of commit message is enough.
05:07 <hyperair> Circuitsoft: that would be awesome, but as far as i can tell, it isn't used atm
05:07 <hyperair> now then are there any git devs we can propose this to? =p
05:07 <context> <-- gets all credit
05:07 <context> and his million dollar prize
05:08 <hyperair> lol
05:08 <Ilari> hyperair: Send idea to mailinglist. The official policy is essentially that altough this channel has archives, for development purposes discussions here never happned.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: GPG signing for git commit?
From: Linus Torvalds @ 2009-04-03 22:54 UTC (permalink / raw)
To: Chow Loong Jin; +Cc: git
In-Reply-To: <1238793954.19982.14.camel@hyperair-laptop>
On Sat, 4 Apr 2009, Chow Loong Jin wrote:
>
> It crossed my mind that currently git commits cannot actually be
> verified to be authentic, due to the fact that I can just set my
> identity to be someone else, and then commit under their name.
You can't do that.
Well, you can, but it's always going to be inferior to just adding a tag.
The thing is, what is it you want to protect? The tree, the authorship,
the committer info, the commit log, what?
And it really does matter. Because the signature must be over some part of
the commit, and since the SHA1 of the commit by definition contains
everything, then the _safest_ thing is always to sign the SHA1 itself:
thus a tag.
Anything else is always bound to only sign a _part_ of the commit. What
part do you feel like protecting? Or put another way, what part do you
feel like _not_ protecting?
So the way git does signatures protects everything. When you do a tag with
"git tag -s" on a commit, you can absolutely _know_ that nobody will ever
modify that commit in any way without the tag signature becoming invalid.
And perhaps equally interestingly, that signature is now also easily
separable from the history - which is interesting if you want to
distribute your cryptographic parts separately (for example, you only use
it _internally_ within a company or group, to mark some group-specific
issues).
Also, related to that "separable" - the person signing on something is not
necessarily the person marked as author, or even committing it anyway. One
of the guiding goals for git was always that it should work well with
"outside" flows, ie others passing patches around or using other SCM's to
manage their own flow.
Finally, on that same "separable" notion - imagine a big rewrite operation
for whatever reason - like a big import into git, or a project re-writing
their history because they ended up importing more history from old
sources (or because they wanted to split a big project into subprojects).
All of those invalidate any cryptographic signatures.
And all of those are events that you may still want to _update_ the
signatures, but do you want to trust the one doing the conversion with the
private keys? Obviously not. You could "wrap" the signing in a new
"conversion signature", and have a signature to try to imply that the
person doing the conversion "signs" the conversion. But the fact is, that
doesn't mean the same thing.
With separate signatures (ie the "git tag -s" model), you can ask the
people who signed the original repository to consider re-signing the
rewritten one. See? Safe, flexible, and much superior.
The exact same thing goes for keys that get invalidated because they ended
up being shown to be too weak or just flawed some other way, btw. That is
a reason to re-sign, _without_ the repository necessarily changing.
You can do _none_ of these things sanely if you put the signatures into
the commits themselves.
So don't do it.
Btw, there's a final reason, and probably the really real one. Signing
each commit is totally stupid. It just means that you automate it, and you
make the signature worth less. It also doesn't add any real value, since
the way the git DAG-chain of SHA1's work, you only ever need _one_
signature to make all the commits reachable from that one be effectively
covered by that one. So signing each commit is simply missing the point.
IOW, you don't _ever_ have a reason to sign anythign but the "tip". The
only exception is the "go back and re-sign", but that's the one that
requires external signatures anyway.
So be happy with 'git tag -s'. It really is the right way.
Linus
^ permalink raw reply
* Re: [PATCH] Add custom memory allocator to MinGW and MacOS builds
From: Johannes Schindelin @ 2009-04-03 23:16 UTC (permalink / raw)
To: Pat Thoyts; +Cc: marius, git, msysgit
In-Reply-To: <a5b261830904031412o60b7eb4fv7e25a2ca4f89fe60@mail.gmail.com>
Hi,
On Fri, 3 Apr 2009, Pat Thoyts wrote:
> 2009/4/3 Marius Storm-Olsen <marius@trolltech.com>:
> >
> > Marius Storm-Olsen said the following on 03.04.2009 15:52:
> >> The standard allocator on Windows is pretty bad prior to Windows
> >> Vista, and nedmalloc is better than the modified dlmalloc provided
> >> with newer versions of the MinGW libc.
> >
> > Actually, it just struck me that it's probably the synchronization
> > primitives which are better on Vista than XP, and not the memory
> > manager? (Since mingw 4.3.3-tdm on XP and Vista most likely use the
> > same dlmalloc fork?) ^shrug^
> >
> > Anyways, not that I haven't tried to 'tune' nedmalloc in any way, just
> > ensured that it compiles with the different MinGWs which I
> > benchmarked. So, if anyone feels like it, maybe we can squeeze more
> > performance out of it by tweaking it.
>
> The difference on Windows Vista is that the low fragmentation heap is
> the default memory allocator. On Windows XP you need to enable it
> specifically for an application. So a possible alternative to this is
> just to enable the low fragmentation heap. (done via GetProcessHeaps and
> HeapSetInformation Win32 API calls).
Does this also work on NT?
Ciao,
Dscho
^ permalink raw reply
* Re: [msysGit] Re: [PATCH] Add custom memory allocator to MinGW and MacOS builds
From: Pat Thoyts @ 2009-04-03 23:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: marius, git, msysgit
In-Reply-To: <alpine.DEB.1.00.0904040116300.10279@pacific.mpi-cbg.de>
2009/4/3 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> On Fri, 3 Apr 2009, Pat Thoyts wrote:
[snip]
>> The difference on Windows Vista is that the low fragmentation heap is
>> the default memory allocator. On Windows XP you need to enable it
>> specifically for an application. So a possible alternative to this is
>> just to enable the low fragmentation heap. (done via GetProcessHeaps and
>> HeapSetInformation Win32 API calls).
>
> Does this also work on NT?
>
> Ciao,
> Dscho
No - the low fragmentation heap was added as an option to Windows XP
and became the default heap in Vista. XP or Server 2003 are
documentated as the lowest versions supporting this on MSDN.
Pat Thoyts
^ permalink raw reply
* git diff bug?
From: David Abrahams @ 2009-04-04 1:10 UTC (permalink / raw)
To: git
Please see
http://github.com/techarcana/elisp/commit/63d672c296316c85690085930b05c642b88a9978#diff-2
Note how the @@ ... @@ clauses are followed by text from the previous
line's comment. Not sure, but this strikes me as a line-ending issue.
custom.el was originally built on a linux machine; now I'm using a Mac.
Thanks!
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
^ permalink raw reply
* Re: [PATCH] mailmap: resurrect lower-casing of email addresses
From: A Large Angry SCM @ 2009-04-04 1:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0904030447480.10279@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 2 Apr 2009, A Large Angry SCM wrote:
>
>> Johannes Schindelin wrote:
>>
>>> On Thu, 2 Apr 2009, A Large Angry SCM wrote:
>>>
>>>> Junio C Hamano wrote:
>>>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>>>
>>>>>>> What part of the email address is this going to lowercase?
>>>>>>> Only the domain name is case agnostic.
>>>>> That is my understanding of RFC, too. Let's see where this mail
>>>>> goes to find out how much more lenient the real world is ;-).
>>>>>
>>>> Many email providers/servers are lenient when it comes to case in
>>>> the local part of an email address (after all, they control the
>>>> interpretation) but not every provider/server is and the RFC is VERY
>>>> clear on this issue.
>>> And in one of my projects it is _very_ clear that this strict
>>> interpretation of the RFC, which does not matter in reality,
>>> _actively_ _hurts_.
>> Care to provide actual justification for that statement.
>
> Well, I _did_! I have at least _one_ repository where the case
> insensitive email addresses worked, and got fscked over, by having Git
> change behavior behind my back!
>
>>> In the alternative, can I ask you to adjust my .mailmap in your free
>>> time?
>> _Your_ .mailmap file is your issue.
>>
>> So which standards do you choose to follow and which do you choose to
>> ignore?
>
> You chose a rather inappropriate moment to start one of those damned
> flamewars -- I am in the middle of some rather important day-job meeting,
> plus two projects in the deadline-is-looming GSoC frenzy.
>
> In case it was not clear yet: if I have to chose between following a
> standard and reality that just took over, I will _always_ choose the
> latter.
>
> If you take this mail to start a flamewar for real (i.e. not answer to my
> concerns, but point out that standard X says bla, and that everybody else
> should just obey, oh, and fix their ways as of 20 years), please do remove
> me from the Cc: list.
>
> Ciao,
> Dscho
> )
>
Sorry, this is not a flame war (and as Peff already sent a response that
superior to my own) so I'll let Junio decide.
However, to keep the peace (and as a thank you for all the hard work to
date, I'll say that I'm scheduled to be be Germany and Munich the first
10 days in October and I'll buy the first $100 dollars in drinks at any
meet that participate in (as a thank you to all the hard work for git
that has been performed) that may happen that I participate in).
^ permalink raw reply
* Re: git diff bug?
From: Jeff King @ 2009-04-04 1:45 UTC (permalink / raw)
To: David Abrahams; +Cc: git
In-Reply-To: <m2ocvdkyul.fsf@boostpro.com>
On Fri, Apr 03, 2009 at 09:10:42PM -0400, David Abrahams wrote:
> Please see
> http://github.com/techarcana/elisp/commit/63d672c296316c85690085930b05c642b88a9978#diff-2
>
> Note how the @@ ... @@ clauses are followed by text from the previous
> line's comment. Not sure, but this strikes me as a line-ending issue.
> custom.el was originally built on a linux machine; now I'm using a Mac.
This is as designed. The original file ("git show e7dd7db") contains (my
numbering seems different than what git produces; it is produced by "nl"
which is maybe treating some line endings differently earlier in the
file):
102 '(mm-attachment-override-types (quote ("text/x-vcard" "application/pkcs7-mime" "application/x-pkcs7-mime" "application/pkcs7-signature" "application/x-pkcs7-signature" "image/*")) nil nil "
103 Added image/* to display attached images inline")
104 '(mm-discouraged-alternatives (quote ("text/html" "text/richtext" "image/.*")) nil nil "
105 The documentation for this variable says it all")
106 '(mm-inline-text-html-with-images t)
107 '(muse-project-alist (quote (("WikiPlanner" ("~/plans" :default "index" :major-mode planner-mode :visit-link planner-visit-link)))))
108 '(org-agenda-files (quote ("~/organizer.org")))
The changed text in your diff starts on 108. So we show 105-107 as
context lines. The text after the @@ clause is the "function header";
this is equivalent to "-p" in GNU diff. It's basically a guess about the
most interesting context to show, and looks alphabetic characters that
are left-aligned. In the case of lisp, it really isn't all that
interesting (and what looks so weird is that your file contains
a lot of
"\nSome text"
so the text strings are all left-aligned. You can customize the regex
used to guess at the function header. See "defining a custom
hunk-header" in "git help attributes".
-Peff
^ permalink raw reply
* Re: [PATCH] mailmap: resurrect lower-casing of email addresses
From: A Large Angry SCM @ 2009-04-04 1:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0904030447480.10279@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 2 Apr 2009, A Large Angry SCM wrote:
>
>> Johannes Schindelin wrote:
>>
>>> On Thu, 2 Apr 2009, A Large Angry SCM wrote:
>>>
>>>> Junio C Hamano wrote:
>>>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>>>
>>>>>>> What part of the email address is this going to lowercase?
>>>>>>> Only the domain name is case agnostic.
>>>>> That is my understanding of RFC, too. Let's see where this mail
>>>>> goes to find out how much more lenient the real world is ;-).
>>>>>
>>>> Many email providers/servers are lenient when it comes to case in
>>>> the local part of an email address (after all, they control the
>>>> interpretation) but not every provider/server is and the RFC is VERY
>>>> clear on this issue.
>>> And in one of my projects it is _very_ clear that this strict
>>> interpretation of the RFC, which does not matter in reality,
>>> _actively_ _hurts_.
>> Care to provide actual justification for that statement.
>
> Well, I _did_! I have at least _one_ repository where the case
> insensitive email addresses worked, and got fscked over, by having Git
> change behavior behind my back!
>
>>> In the alternative, can I ask you to adjust my .mailmap in your free
>>> time?
>> _Your_ .mailmap file is your issue.
>>
>> So which standards do you choose to follow and which do you choose to
>> ignore?
>
> You chose a rather inappropriate moment to start one of those damned
> flamewars -- I am in the middle of some rather important day-job meeting,
> plus two projects in the deadline-is-looming GSoC frenzy.
>
> In case it was not clear yet: if I have to chose between following a
> standard and reality that just took over, I will _always_ choose the
> latter.
>
> If you take this mail to start a flamewar for real (i.e. not answer to my
> concerns, but point out that standard X says bla, and that everybody else
> should just obey, oh, and fix their ways as of 20 years), please do remove
> me from the Cc: list.
This is not worth a flame-war, and Peff has already created a response
superior to my own, so I'll leave to Junio to find the best(TM) path.
^ permalink raw reply
* Re: git diff bug?
From: Jeff King @ 2009-04-04 1:52 UTC (permalink / raw)
To: David Abrahams; +Cc: git
In-Reply-To: <20090404014527.GA13350@coredump.intra.peff.net>
On Fri, Apr 03, 2009 at 09:45:27PM -0400, Jeff King wrote:
> This is as designed. The original file ("git show e7dd7db") contains (my
> numbering seems different than what git produces; it is produced by "nl"
> which is maybe treating some line endings differently earlier in the
> file):
Sorry, this was just me failing to use "nl" correctly. I needed to use
"-ba" to number empty lines. So the line numbers do match git, and the
rest of my explanation holds.
-Peff
^ 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