* Re: tr/pty-all (Re: What's cooking in git.git (Dec 2011, #04; Tue, 13))
From: Junio C Hamano @ 2011-12-15 3:23 UTC (permalink / raw)
To: Jeff King
Cc: Jonathan Nieder, Thomas Rast, git,
Nguyễn Thái Ngọc Duy, Michael Haggerty
In-Reply-To: <20111215005057.GB2566@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> This correctly detects the bug in t7006. I can't decide if it's clever
> or ugly.
I would say it falls on the latter side of the line by small margin. Let's
do the /dev/null thing and be done with it.
^ permalink raw reply
* Re: [BUG] in rev-parse
From: Junio C Hamano @ 2011-12-15 3:20 UTC (permalink / raw)
To: Jeff King; +Cc: nathan.panike, git
In-Reply-To: <20111214210157.GA8990@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On the other hand, it has been like this since it was introduced in
> 2006, and I wonder if scripts rely on the --verify side effect.
It would have been nicer if it did not to imply --verify at all; a long
hexdigit that do not name an existing object at all will be shortened to
its prefix that still do not collide with an abbreviated object name of an
existing object, and even in such a case, the command should not error out
only because it was fed a non-existing object (of course, if "--verify" is
given at the same time, its "one input that names existing object only"
rule should also kick in).
^ permalink raw reply
* Re: [PATCH 3/3] Do not create commits whose message contains NUL
From: Junio C Hamano @ 2011-12-15 3:09 UTC (permalink / raw)
To: Jeff King; +Cc: Miles Bader, Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20111215011855.GA24568@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Perhaps it should just be dropped.
Thanks. I have nothing to add---you said everything that needs to be said.
^ permalink raw reply
* Re: [RFC PATCH 2/4] test-lib: allow testing another git build tree
From: Junio C Hamano @ 2011-12-15 3:07 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Michael Haggerty
In-Reply-To: <94f64a03398829bb9a11c18577efb39d9b153eca.1323876121.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> The perf-lib work wants this feature, so we may as well do it for
> test-lib in general.
How is this different from what GIT_TEST_INSTALLED already gives us
(other than "needs more diskspace to keep another source tree fully
built", that is)?
^ permalink raw reply
* Re: process committed files in post-receive hook
From: Hao Wang @ 2011-12-15 2:02 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
In-Reply-To: <4EE94783.1010805@gmail.com>
Thank you all for providing the options. Just so you know I finally went
with Alexey's suggestion. I used 'git show' to get both a list of files
in a directory and the content of each file. It works great on a bare
repository so there is no need to check out a copy on the server.
Below is the python code in my post-receive hook for this task, where
rev is something like 'HEAD:directory_name' for the first function and
'HEAD:directory/filename' for the second function.
# get a list of rule files using git show
def getRuleFileList(rev):
# run git show
p = subprocess.Popen(['git', 'show', rev], stdout=subprocess.PIPE)
p.wait()
if p.returncode != 0: return None # error
# parse output
i = 0
filelist = []
for line in p.stdout.readlines():
filelist.append(line)
p.stdout.close()
return filelist
# read the content of a file
def readfile(rev):
# run git show
p = subprocess.Popen(['git', 'show', rev], stdout=subprocess.PIPE)
p.wait()
if p.returncode != 0: return None # error
return p.stdout.read()
Hao
On 12/14/11 5:04 PM, Neal Kreitzinger wrote:
> On 12/10/2011 4:29 AM, Hao wrote:
>> Hi guys,
>>
>> I am writing a post-receive hook in Python that examines the content
>> of some files (the HEAD rev). Because the repo is a bare one on the
>> server. My current approach is to check out a working copy on the
>> server and run 'git pull' in post- receive to get the most up-to-date
>> version, and then process files in the working copy.
>>
>> I have two questions. First, is there a way that I can access file
>> content in a bare repo without checking out a working copy? If this
>> is not possible, my approach would be reasonable. However, when 'git
>> pull' was called in the python script post-receive when a commit
>> occurs, it gives an error.
>>
>> remote: fatal: Not a git repository: '.'
>>
>> The call in python is
>>
>> subprocess.Popen(["git", "pull"],
>> cwd="/Users/git/ts.git.workingcopy")
>>
>> I read from a post (http://stackoverflow.com/questions/4043609/) that
>> GIT_DIR is causing this error. Is it safe to unset GIT_DIR in
>> post-receive?
>>
> The specific processing you intend to perform on the files would
> determine which of the access techniques is appropriate for you.
> Generally speaking, I think a checkout in a non-bare repo makes sense.
> You could limit it to a shallow clone (see git-clone manpage) to save
> space.
>
> Another way to get the files is git-archive (creates tar file), that you
> could extract to a dir for processing.
>
> In both cases, you need to consider the default permissions in play with
> git-checkout and git-archive if permissions are important in your
> processing.
>
> v/r,
> neal
^ permalink raw reply
* Re: [PATCH 3/3] Do not create commits whose message contains NUL
From: Jeff King @ 2011-12-15 1:18 UTC (permalink / raw)
To: Miles Bader; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <CADCnXoaqEXJV+Mb1=nQge_bjA3H6R7=BPt213CKLX55zyTHEtg@mail.gmail.com>
On Thu, Dec 15, 2011 at 10:04:06AM +0900, Miles Bader wrote:
> > + commitWideEncoding::
> > + Advice shown when linkgit::git-commit[1] refuses to
> > + proceed because there are NULs in commit message.
> > + Default: true.
>
> Although "wide encoding" is a reasonable guess at cause of embedded
> zero characters (and so a useful term for diagnostic messages, as it
> can help users identify the problem in their environment which is
> causing such zero bytes), it's really only a guess in most cases...
>
> Shouldn't the variable be named based on what it actually does, which
> is allow zero-bytes in commit messages...?
I agree, but...
Really this variable is overkill. The advice.* subsystem is for
silencing hints and warnings from git that you see repeatedly because
you are smarter than git, and want to ignore its advice.
But in this case, I don't see a user saying "stupid git, of _course_ I
want to commit NULs. Stop nagging me". Especially because it is not a
warning, but a fatal error. :)
So yes, it's verbose, but no, it's not something somebody is going to be
so bothered by that they will find the config option to turn it off.
Instead, they will stop doing the bad thing and never see it again. At
best this config option is useless, and at worst it clutters the
advice.* namespace, making it harder for people to find the advice
option they _do_ want to turn off).
Perhaps it should just be dropped.
-Peff
^ permalink raw reply
* Re: [PATCH 3/3] Do not create commits whose message contains NUL
From: Miles Bader @ 2011-12-15 1:04 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jeff King
In-Reply-To: <1323871699-8839-4-git-send-email-pclouds@gmail.com>
> + commitWideEncoding::
> + Advice shown when linkgit::git-commit[1] refuses to
> + proceed because there are NULs in commit message.
> + Default: true.
Although "wide encoding" is a reasonable guess at cause of embedded
zero characters (and so a useful term for diagnostic messages, as it
can help users identify the problem in their environment which is
causing such zero bytes), it's really only a guess in most cases...
Shouldn't the variable be named based on what it actually does, which
is allow zero-bytes in commit messages...?
-Miles
--
Cat is power. Cat is peace.
^ permalink raw reply
* Re: process committed files in post-receive hook
From: Neal Kreitzinger @ 2011-12-15 1:04 UTC (permalink / raw)
To: Hao; +Cc: git
In-Reply-To: <loom.20111210T111457-837@post.gmane.org>
On 12/10/2011 4:29 AM, Hao wrote:
> Hi guys,
>
> I am writing a post-receive hook in Python that examines the content
> of some files (the HEAD rev). Because the repo is a bare one on the
> server. My current approach is to check out a working copy on the
> server and run 'git pull' in post- receive to get the most up-to-date
> version, and then process files in the working copy.
>
> I have two questions. First, is there a way that I can access file
> content in a bare repo without checking out a working copy? If this
> is not possible, my approach would be reasonable. However, when 'git
> pull' was called in the python script post-receive when a commit
> occurs, it gives an error.
>
> remote: fatal: Not a git repository: '.'
>
> The call in python is
>
> subprocess.Popen(["git", "pull"],
> cwd="/Users/git/ts.git.workingcopy")
>
> I read from a post (http://stackoverflow.com/questions/4043609/) that
> GIT_DIR is causing this error. Is it safe to unset GIT_DIR in
> post-receive?
>
The specific processing you intend to perform on the files would
determine which of the access techniques is appropriate for you.
Generally speaking, I think a checkout in a non-bare repo makes sense.
You could limit it to a shallow clone (see git-clone manpage) to save space.
Another way to get the files is git-archive (creates tar file), that you
could extract to a dir for processing.
In both cases, you need to consider the default permissions in play with
git-checkout and git-archive if permissions are important in your
processing.
v/r,
neal
^ permalink raw reply
* Re: tr/pty-all (Re: What's cooking in git.git (Dec 2011, #04; Tue, 13))
From: Jeff King @ 2011-12-15 0:50 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Thomas Rast, Junio C Hamano, git,
Nguyễn Thái Ngọc Duy, Michael Haggerty
In-Reply-To: <20111215002530.GA2566@sigill.intra.peff.net>
On Wed, Dec 14, 2011 at 07:25:30PM -0500, Jeff King wrote:
> [1] Actually, you could abandon the idea of feeding garbage altogether,
> and instead open the descriptor outside the test, then check that its
> offset is still 0 after the test. You'd have to use a helper program to
> do the ftell(), but it should work as the descriptor position will be
> shared.
And here's what that patch would look like. You still want to feed a
garbage file, because you want to make sure that there is something for
it to actually read. And then either it can choke on the garbage and
fail, or if not, you can detect afterwards that it was read.
This correctly detects the bug in t7006. I can't decide if it's clever
or ugly.
---
t/stdin-garbage | 1 +
t/test-lib.sh | 16 ++++++++++++++++
2 files changed, 17 insertions(+), 0 deletions(-)
create mode 100644 t/stdin-garbage
diff --git a/t/stdin-garbage b/t/stdin-garbage
new file mode 100644
index 0000000..3a2ebc2
--- /dev/null
+++ b/t/stdin-garbage
@@ -0,0 +1 @@
+This is a garbage file that will be connected to the stdin of each test.
diff --git a/t/test-lib.sh b/t/test-lib.sh
index bdd9513..9b4692b 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -466,6 +466,10 @@ test_debug () {
test "$debug" = "" || eval "$1"
}
+test_stdin_unread_ () {
+ test "`perl -e 'print tell(STDIN)'`" = 0
+}
+
test_eval_ () {
# This is a separate function because some tests use
# "return" to end a test_expect_success block early.
@@ -475,9 +479,21 @@ test_eval_ () {
test_run_ () {
test_cleanup=:
expecting_failure=$2
+ # feed the test a bogus stdin, but keep a spare descriptor open in case
+ # the test redirects stdin, which affects us since it is an eval
+ exec 6<&0
+ exec 7<"$TEST_DIRECTORY/stdin-garbage"
+ exec 0<&7
test_eval_ "$1"
eval_ret=$?
+ # check that nobody read from our bogus descriptor
+ if test $eval_ret = 0 && ! test_stdin_unread_ <&7; then
+ echo >&4 "bug in the test script: somebody read from stdin"
+ eval_ret=1
+ fi
+ exec 0<&6
+
if test -z "$immediate" || test $eval_ret = 0 || test -n "$expecting_failure"
then
test_eval_ "$test_cleanup"
--
1.7.8.rc2.30.g803b1a
^ permalink raw reply related
* Re: tr/pty-all (Re: What's cooking in git.git (Dec 2011, #04; Tue, 13))
From: Jeff King @ 2011-12-15 0:25 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Thomas Rast, Junio C Hamano, git,
Nguyễn Thái Ngọc Duy, Michael Haggerty
In-Reply-To: <20111214233119.GA2354@elie>
On Wed, Dec 14, 2011 at 05:31:19PM -0600, Jonathan Nieder wrote:
> > @@ -469,7 +471,7 @@ test_debug () {
> > test_eval_ () {
> > # This is a separate function because some tests use
> > # "return" to end a test_expect_success block early.
> > - eval >&3 2>&4 "$*"
> > + eval <"$TEST_DIRECTORY/stdin-garbage" >&3 2>&4 "$*"
>
> How about /dev/urandom on platforms that support it? It wouldn't be
> as pleasant to debug as "This is a magic stdin garbage stream", but it
> would be more likely to (despite the name :)) predictably trip errors,
> or at least hangs, in problematic tests.
I'd rather have something deterministic. If you really want to be mean
to accidental readers of stdin, then put binary junk into stdin-garbage
(even the results of a single run of /dev/urandom, if you like). But I
suspect arbitrary text is good enough to throw a monkey wrench into
anything that will care about its input (and those that don't are beyond
our ability to auto-detect anyway[1]). And it's way easier to debug than
seeing random binary bits.
-Peff
[1] Actually, you could abandon the idea of feeding garbage altogether,
and instead open the descriptor outside the test, then check that its
offset is still 0 after the test. You'd have to use a helper program to
do the ftell(), but it should work as the descriptor position will be
shared.
^ permalink raw reply
* How to commit incomplete changes?
From: Hallvard B Furuseth @ 2011-12-14 23:24 UTC (permalink / raw)
To: git
Do people have any feelings or conventions for how and when to publish
a series of commits where the first one(s) break something and the next
ones clear it up? I've found some discussion, but with vague results.
I'm about to commit some small edits which go together with bigger
generated changes. It seems both more readable and more cherry-pick-
friendly to me to keep these in separate commits.
What I've found is I can use a line in the commit message like
"Incomplete change, requires next commit (update foo/ dir)."
and, if there is any point, do a no-ff merge past the breakage.
--
Hallvard
^ permalink raw reply
* Re: tr/pty-all (Re: What's cooking in git.git (Dec 2011, #04; Tue, 13))
From: Jonathan Nieder @ 2011-12-14 23:31 UTC (permalink / raw)
To: Jeff King
Cc: Thomas Rast, Junio C Hamano, git,
Nguyễn Thái Ngọc Duy, Michael Haggerty
In-Reply-To: <20111214232151.GB13128@sigill.intra.peff.net>
Jeff King wrote:
[...]
> A test which accidentally reads stdin would soak up all of
> the rest of the input intended for the outer shell loop.
>
> Let's redirect stdin from a known source to eliminate
> variation. We could just connect it to /dev/null. However,
> tests which accidentally read stdin would then see immediate
> EOF, which may or may not cause them to notice the errror.
[...]
> +++ b/t/test-lib.sh
[...]
> @@ -469,7 +471,7 @@ test_debug () {
> test_eval_ () {
> # This is a separate function because some tests use
> # "return" to end a test_expect_success block early.
> - eval >&3 2>&4 "$*"
> + eval <"$TEST_DIRECTORY/stdin-garbage" >&3 2>&4 "$*"
How about /dev/urandom on platforms that support it? It wouldn't be
as pleasant to debug as "This is a magic stdin garbage stream", but it
would be more likely to (despite the name :)) predictably trip errors,
or at least hangs, in problematic tests.
With or without something along those lines on top, your patch looks
like a good change.
Thanks for a thoughtful analysis.
Jonathan
^ permalink raw reply
* Re: tr/pty-all (Re: What's cooking in git.git (Dec 2011, #04; Tue, 13))
From: Jeff King @ 2011-12-14 23:21 UTC (permalink / raw)
To: Thomas Rast
Cc: Jonathan Nieder, Junio C Hamano, git,
Nguyễn Thái Ngọc Duy, Michael Haggerty
In-Reply-To: <20111214230713.GA13128@sigill.intra.peff.net>
On Wed, Dec 14, 2011 at 06:07:13PM -0500, Jeff King wrote:
> On Wed, Dec 14, 2011 at 05:17:14PM +0100, Thomas Rast wrote:
>
> > > I also find Jeff's patch [3] appealing.
> >
> > Me too, though wonder whether feeding a file full of garbage wouldn't
> > be better, so as to trip up commands that try to read only from a
> > non-tty stdin.
>
> Interesting idea. Instead of getting an immediate EOF from /dev/null,
> they'll get some junk which they may or may not complain about. I played
> around with this a bit, redirecting test stdin from a file with:
So here is what that patch looked like. As I mentioned, it doesn't
actually catch the shortlog problem, but it would fix
Michael's issue with an outer reading loop.
-- >8 --
Subject: [PATCH] test-lib: redirect stdin of tests
We want to run tests in a predictable, sterile environment
so we can get repeatable results. They should take as
little input as possible from the environment outside the
test script. We already sanitize environment variables, but
leave stdin untouched. This means that scripts can
accidentally be impacted by content on stdin, or whether
stdin isatty().
Furthermore, scripts reading from stdin can be annoying to
outer loops which care about their stdin offset, like:
while read sha1; do
make test
done
A test which accidentally reads stdin would soak up all of
the rest of the input intended for the outer shell loop.
Let's redirect stdin from a known source to eliminate
variation. We could just connect it to /dev/null. However,
tests which accidentally read stdin would then see immediate
EOF, which may or may not cause them to notice the errror.
Instead, let's connect it to a file with random garbage in
it, in the hope that it will be more likely to trigger an
error in the mis-written test.
We'll also leave file descriptor 6 as a link to the original
stdin. Tests shouldn't need to look at this, but it can be
convenient for inserting interactive commands while
debugging tests (e.g., you could insert "bash <&6 >&3 2>&4"
to run interactive commands in the environment of the test
script).
Signed-off-by: Jeff King <peff@peff.net>
---
t/stdin-garbage | 1 +
t/test-lib.sh | 4 +++-
2 files changed, 4 insertions(+), 1 deletions(-)
create mode 100644 t/stdin-garbage
diff --git a/t/stdin-garbage b/t/stdin-garbage
new file mode 100644
index 0000000..3a2ebc2
--- /dev/null
+++ b/t/stdin-garbage
@@ -0,0 +1 @@
+This is a garbage file that will be connected to the stdin of each test.
diff --git a/t/test-lib.sh b/t/test-lib.sh
index bdd9513..67eb078 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -198,6 +198,8 @@ else
exec 4>/dev/null 3>/dev/null
fi
+exec 6<&0
+
test_failure=0
test_count=0
test_fixed=0
@@ -469,7 +471,7 @@ test_debug () {
test_eval_ () {
# This is a separate function because some tests use
# "return" to end a test_expect_success block early.
- eval >&3 2>&4 "$*"
+ eval <"$TEST_DIRECTORY/stdin-garbage" >&3 2>&4 "$*"
}
test_run_ () {
--
1.7.8.rc2.30.g803b1a
^ permalink raw reply related
* Re: tr/pty-all (Re: What's cooking in git.git (Dec 2011, #04; Tue, 13))
From: Jeff King @ 2011-12-14 23:07 UTC (permalink / raw)
To: Thomas Rast
Cc: Jonathan Nieder, Junio C Hamano, git,
Nguyễn Thái Ngọc Duy, Michael Haggerty
In-Reply-To: <201112141717.15021.trast@student.ethz.ch>
On Wed, Dec 14, 2011 at 05:17:14PM +0100, Thomas Rast wrote:
> > I also find Jeff's patch [3] appealing.
>
> Me too, though wonder whether feeding a file full of garbage wouldn't
> be better, so as to trip up commands that try to read only from a
> non-tty stdin.
Interesting idea. Instead of getting an immediate EOF from /dev/null,
they'll get some junk which they may or may not complain about. I played
around with this a bit, redirecting test stdin from a file with:
This is a garbage file that will be connected to the stdin of each
test.
(with the hope that when you see that in an error message, it will be
obvious what has happened).
It turns out that shortlog (the one bug of this type in the test suite)
doesn't care at all. It will happily chew on that garbage and behave
just the same as if it had been given /dev/null.
There is also the minor issue that if there are multiple invocations of
the input-chewing command, the first one will eat all of the input, and
subsequent ones will just get the equivalent of /dev/null anyway. I.e.:
test_expect_success 'git shortlog $foo' ;# will eat all of our stdin
test_expect_success 'git shortlog $bar' ;# sees immediate EOF
That may not matter, though, as you would hope for the first invocation
to complain, at which point you fix it, revealing the failures in later
tests (or if you're clever, noticing in the first place that they all
have the same bug).
You can make this somewhat more robust by redirecting stdin for
_test_eval (so each test gets a fresh descriptor to the garbage file).
However, that disallows redirecting a specific test's stdin in the test
script, like:
test_expect_success 'some test' '
cat >expect &&
some_command >actual &&
test_cmp expect actual
' <<\EOF
the expected
data
EOF
This construct probably seems silly at first, but see how it is used in
t6006:
test_format author %an%n%ae%n%ad%n%aD%n%at <<\EOF
commit ...
A U Thor
author@example.com
... etc ...
EOF
where test_format is a generic function that just gobbles stdin into the
"expect" file. As it turns out, test_format actually runs the "cat"
outside of the "test_expect_success", but quite often we put it inside.
So maybe it isn't worth caring about. You could also argue that the
whole thing should just be inside a test_expect_success.
-Peff
^ permalink raw reply
* Re: Suppressing the user.name warning
From: Jeff King @ 2011-12-14 22:16 UTC (permalink / raw)
To: Jay Levitt; +Cc: git@vger.kernel.org
In-Reply-To: <4EE91A1D.6080908@gmail.com>
On Wed, Dec 14, 2011 at 04:50:21PM -0500, Jay Levitt wrote:
> Is there a way to suppress the user.name/email warning without
> configuring them in .gitconfig? I want to pass them in SSH as
> GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL; git uses the values, but still
> warns me every time.
>
> Seems like if git can get that data in any form, it shouldn't
> complain about not having it. No?
Git should not be complaining if it gets the data from the environment.
However, you should also be setting GIT_COMMITTER_NAME and
GIT_COMMITTER_EMAIL. Otherwise they will come from the passwd file, and
git will issue the warning.
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] run-command: Add checks after execvp fails with EACCES
From: Frans Klaver @ 2011-12-14 22:06 UTC (permalink / raw)
To: Junio C Hamano, Frans Klaver; +Cc: git
In-Reply-To: <CAH6sp9Mf=EjkVN9mDN59ZCxCU0sCFLa8E=7YxM1J8LCCMr=xYQ@mail.gmail.com>
On Wed, 14 Dec 2011 15:31:25 +0100, Frans Klaver <fransklaver@gmail.com>
wrote:
> Since fopen() uses the effective uid/gid, it then makes sense to use
> eaccess(3) instead of access(2) if available. It would be stupid to
> have bugs arise just because of a mismatch between the [ug]ids used by
> the two access checks. I'm aware of the fact that eaccess isn't a
> standard function, so a #define HAVE... fallback to at least access()
> would probably be required.
Just to be clear, I don't really want to restart the discussion of which
uid to use, but it is something to consider now or in the future. The next
roll will use access(2) as far as I'm concerned.
^ permalink raw reply
* Re: How to run http server tests?
From: Johannes Sixt @ 2011-12-14 22:02 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20111214213952.GA11519@sigill.intra.peff.net>
Am 14.12.2011 22:39, schrieb Jeff King:
> On Wed, Dec 14, 2011 at 10:20:07PM +0100, Johannes Sixt wrote:
>> diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
>> index 0a4cdfa..e5cb3f9 100644
>> --- a/t/lib-httpd/apache.conf
>> +++ b/t/lib-httpd/apache.conf
>> @@ -13,4 +13,4 @@ ErrorLog error.log
>> </IfModule>
>> -<IfModule !mod_cgi.c>
>> - LoadModule cgi_module modules/mod_cgi.so
>> +<IfModule !mod_scgi.c>
>> + LoadModule scgi_module modules/mod_scgi.so
>> </IfModule>
>
> Hmm. I know nothing about scgi, but a quick google indicates that it is
> a separate protocol from CGI and is more like FastCGI (i.e., it wants to
> spawn a long-running CGI server and contact it over a separate
> protocol).
>
> So I suspect you are not able to run http-backend, and thus you have no
> smart-http support in your setup.
Thanks, that put me on the right track. I have to use
LIB_HTTPD_MODULE_PATH=/usr/lib64/apache2-prefork
-- Hannes
^ permalink raw reply
* Suppressing the user.name warning
From: Jay Levitt @ 2011-12-14 21:50 UTC (permalink / raw)
To: git@vger.kernel.org
Is there a way to suppress the user.name/email warning without configuring
them in .gitconfig? I want to pass them in SSH as GIT_AUTHOR_NAME and
GIT_AUTHOR_EMAIL; git uses the values, but still warns me every time.
Seems like if git can get that data in any form, it shouldn't complain about
not having it. No?
Jay Levitt
^ permalink raw reply
* Re: How to run http server tests?
From: Jeff King @ 2011-12-14 21:39 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <4EE91307.6080504@kdbg.org>
On Wed, Dec 14, 2011 at 10:20:07PM +0100, Johannes Sixt wrote:
> I have a hard time running tests that use lib-httpd.sh.
>
> I run the tests like this:
>
> LIB_HTTPD_MODULE_PATH=/usr/lib64/apache2 GIT_TEST_HTTPD=Yes \
> sh -x t5541-http-push.sh -v -i
>
> and I have to apply this patch because I do not have mod_cgi on my
> system (OpenSuse 11.4):
>
> diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
> index 0a4cdfa..e5cb3f9 100644
> --- a/t/lib-httpd/apache.conf
> +++ b/t/lib-httpd/apache.conf
> @@ -13,4 +13,4 @@ ErrorLog error.log
> </IfModule>
> -<IfModule !mod_cgi.c>
> - LoadModule cgi_module modules/mod_cgi.so
> +<IfModule !mod_scgi.c>
> + LoadModule scgi_module modules/mod_scgi.so
> </IfModule>
Hmm. I know nothing about scgi, but a quick google indicates that it is
a separate protocol from CGI and is more like FastCGI (i.e., it wants to
spawn a long-running CGI server and contact it over a separate
protocol).
So I suspect you are not able to run http-backend, and thus you have no
smart-http support in your setup.
> I see t5541-http-push.sh #2 fail with:
>
> ++ cd '/home/jsixt/Src/git/git/t/trash directory.t5541-http-push'
> ++ git clone http://127.0.0.1:5541/smart/test_repo.git/ test_repo_clone
> Cloning into 'test_repo_clone'...
> fatal: http://127.0.0.1:5541/smart/test_repo.git/info/refs not found:
> did you run git update-server-info on the server?
That's would I would expect if you have no smart-http support. The git
client will fall back to trying dumb http, but that should fail (because
we haven't run update-server-info).
The other errors you see probably stem from the same issue.
-Peff
^ permalink raw reply
* How to run http server tests?
From: Johannes Sixt @ 2011-12-14 21:20 UTC (permalink / raw)
To: Git Mailing List
I have a hard time running tests that use lib-httpd.sh.
I run the tests like this:
LIB_HTTPD_MODULE_PATH=/usr/lib64/apache2 GIT_TEST_HTTPD=Yes \
sh -x t5541-http-push.sh -v -i
and I have to apply this patch because I do not have mod_cgi on my
system (OpenSuse 11.4):
diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
index 0a4cdfa..e5cb3f9 100644
--- a/t/lib-httpd/apache.conf
+++ b/t/lib-httpd/apache.conf
@@ -13,4 +13,4 @@ ErrorLog error.log
</IfModule>
-<IfModule !mod_cgi.c>
- LoadModule cgi_module modules/mod_cgi.so
+<IfModule !mod_scgi.c>
+ LoadModule scgi_module modules/mod_scgi.so
</IfModule>
I see t5541-http-push.sh #2 fail with:
++ cd '/home/jsixt/Src/git/git/t/trash directory.t5541-http-push'
++ git clone http://127.0.0.1:5541/smart/test_repo.git/ test_repo_clone
Cloning into 'test_repo_clone'...
fatal: http://127.0.0.1:5541/smart/test_repo.git/info/refs not found:
did you run git update-server-info on the server?
t5551-http-fetch.sh fails at #3 here:
++ GIT_CURL_VERBOSE=1
++ git clone --quiet http://127.0.0.1:5551/smart/repo.git clone
+ eval_ret=128
In this case, 'git clone' output is redirected to file 'err'; it has the
same error as above.
t5561-http-backend.sh fails at #3 like so:
+++ diff -u exp act
--- exp 2011-12-14 21:14:49.000000000 +0000
+++ act 2011-12-14 21:14:49.000000000 +0000
@@ -1 +1 @@
-HTTP/1.1 200 OK
+HTTP/1.1 404 Not Found
Can someone help?
Thanks,
-- Hannes
^ permalink raw reply related
* Re: Question about commit message wrapping
From: Sidney San Martín @ 2011-12-14 21:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201112102030.15504.jnareb@gmail.com>
On Dec 10, 2011, at 2:30 PM, Jakub Narebski wrote:
> BTW. In Polish (and Czech) typography there is rule that you don't leave
> single-letter prepositions like 'i' ('and' in English) hanging at the end
> of the line... automatic wrapper cannot ensure that.
I meant to ask… how is that rule followed by browsers/on the web?
^ permalink raw reply
* Re: Question about commit message wrapping
From: Sidney San Martín @ 2011-12-14 21:04 UTC (permalink / raw)
To: Michael Haggerty
Cc: Frans Klaver, Holger Hellmuth, Andrew Ardill, JakubNarebski,
git@vger.kernel.org
In-Reply-To: <4EE6C31C.60909@alum.mit.edu>
On Dec 12, 2011, at 10:14 PM, Michael Haggerty wrote:
> FWIW I think automatic wrapping of commit messages is a bad idea. I
> wrap my commit messages deliberately to make them look the way I want
> them to look. The assumption of an 80-character display has historical
> reasons, but it is also a relatively comfortable line-width to read
> (even on wider displays).
A lot of Git repos live in heterogeneous environments. I played a little with some of the popular Git interfaces I can use on my computer. The majority of them…
- compose and show commit messages in a proportional font (where the width of and formatting in "80 characters" means nothing),
- don’t insert line breaks when you write a commit message (and don't provide a way to do so automatically),
- do wrap commit messages when showing them.
Jakub, you said that education was the answer to getting some consistency in line wrapping, but I have trouble imagining the makers of new tools using fixed-width text for anything other than code.
> And given that commit messages sometimes
> contain "flowable" paragraph text, sometimes code snippets, sometimes
> ASCII art, etc, no automatic wrapping will work correctly unless
> everybody agrees that commit messages must be written in some specific
> form of markup (or lightweight markup). And I can't imagine such a
> thing ever happening.
The two biggest websites I know of for talking about code, GitHub and Stack Overflow, both adopted flavors of Markdown. It is basically the formatting syntax already used for commit messages in the Git project itself (this email too), so can be formatted to look good in a specific environment (i.e. proportional fonts) and looks good by itself.
(Actually, as far as I can tell commit messages are the only place GitHub doesn’t currently render user-entered text as Markdown.)
I think, now and in the future, consistency will be found most easily in in Markdown-like formatting and least in 80 columns of fixed-width text.
- - -
## Gitbox 1.5.1
- Commit messages written and displayed in a proportional font
- Does not insert line breaks when you commit
- When displaying a commit message, turns single line breaks into spaces and keeps double line breaks, wraps as needed based on the size of the viewing area (it's somewhat intelligent about this, it does preserve some line breaks; it doesn't preserve spaces used for formatting)
## Tower 1.0.3
- Commit messages written and displayed in a proportional font
- Does not insert line breaks when you commit. Collapses multiple newlines into a single newline
- When displaying a commit message, wraps at 100 characters and collapses multiple newlines into a single one
## GitHub (Mac app) 1.1.1
- Commit messages written and displayed in a proportional font
- Inserts line breaks after 73 characters when you commit (incl. in the middle of a long identifier)
- Does not wrap lines when displaying commit messages, and doesn’t provide a way to scroll to read them
## GitHub (website)
- Commit messages written and displayed in a fixed-width font
- Does not insert line breaks when you commit, input wraps, visually, at 113 characters
- When displaying a commit message, uses CSS to wrap the commit message to 700 pixels, 100 characters
## git (default configuration in a fresh Linux Mint live cd)
- Does not insert line breaks when you commit (using the default editor (nano) and pager (less, IIRC)
- Does not wrap lines when displaying commit messages.
^ permalink raw reply
* Re: [BUG] in rev-parse
From: Jeff King @ 2011-12-14 21:01 UTC (permalink / raw)
To: nathan.panike; +Cc: git
In-Reply-To: <20111214184926.GB18335@llunet.cs.wisc.edu>
On Wed, Dec 14, 2011 at 12:49:27PM -0600, nathan.panike@gmail.com wrote:
> In my local git.git:
>
> $ git rev-parse 73c6b3575bc638b7096ec913bd91193707e2265d^@
> 57526fde5df201a99afa6d122c3266b3a1c5673a
> 942e6baa92846e5628752c65a22bc4957d8de4d0
>
> $ git rev-parse --short 73c6b3575bc638b7096ec913bd91193707e2265d^@
> 57526fd
> 942e6ba
> fatal: Needed a single revision
>
> ^^^ I don't believe this "fatal" message should be here
It looks like "--short" implies "--verify", and you cannot "--verify"
multiple sha1s.
But the documentation for "--short" says only:
--short::
--short=number::
Instead of outputting the full SHA1 values of object names try to
abbreviate them to a shorter unique name. When no length is specified
7 is used. The minimum length is 4.
which would imply to me that not only should your example work, but this
should, too:
$ git rev-parse HEAD HEAD^
803b1a83b0ec5f04dfb770e83e11211e0015630f
28c2058b6048d32abc0a23b827ab0b26a0332b9b
$ git rev-parse --short HEAD HEAD^
fatal: Needed a single revision
On the other hand, it has been like this since it was introduced in
2006, and I wonder if scripts rely on the --verify side effect.
As a work-around, you can get what you want with:
git rev-list --no-walk --abbrev-commit $sha1^@
-Peff
^ permalink raw reply
* [BUG] in rev-parse
From: nathan.panike @ 2011-12-14 18:49 UTC (permalink / raw)
To: git
In my local git.git:
$ git rev-parse 73c6b3575bc638b7096ec913bd91193707e2265d^@
57526fde5df201a99afa6d122c3266b3a1c5673a
942e6baa92846e5628752c65a22bc4957d8de4d0
$ git rev-parse --short 73c6b3575bc638b7096ec913bd91193707e2265d^@
57526fd
942e6ba
fatal: Needed a single revision
^^^ I don't believe this "fatal" message should be here
$ git version
git version 1.7.8
Nathan Panike
^ permalink raw reply
* Re: [PATCH 3/3] Do not create commits whose message contains NUL
From: Jeff King @ 2011-12-14 18:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy, git, Miles Bader
In-Reply-To: <7vzkevow2j.fsf@alter.siamese.dyndns.org>
On Wed, Dec 14, 2011 at 10:19:16AM -0800, Junio C Hamano wrote:
> Limiting the Porcelain layer to deal only with reasonable text encodings
> (yes, I am declaring that utf16 is not among them) is perfectly fine, but
> I was somehow hoping that you would allow the option for the low-level
> function commit_tree() to create a commit object with binary blob in the
> body part, especially after seeing the patch 1/3 to do so.
>
> Certainly that kind of usage would not give the binary blob literally in
> "git log" output, but it is with or without the issue around NUL byte. A
> custom program linked with commit.c to call commit_tree() may not be using
> the data structure to store anything that is meant to be read by "git log"
> to begin with.
I'm happy to ignore custom programs linking against internal git code,
but what should "git commit-tree" do?
My gut feeling is that it should store the literal binary contents.
However, I don't think this has ever been the case. Even in the initial
version of commit-tree.c, we read the input line-by-line and sprintf it
into place.
-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