* [PATCH RFC 1/2] Smart-http tests: Break test t5560-http-backend into pieces
From: Tarmigan Casebolt @ 2009-12-30 18:59 UTC (permalink / raw)
To: git; +Cc: spearce, gitster, Tarmigan Casebolt
In-Reply-To: <905315640912301009x491f957al839f66de7aba56ed@mail.gmail.com>
This should introduce no functional change in the tests or the amount
of test coverage.
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
---
This is rebased on top of today's pu and the conflicts should be fixed.
t/t5560-http-backend.sh | 148 +-------------------------------------
t/t5561-http-backend-noserver.sh | 52 +++++++++++++
t/t556x_common | 119 ++++++++++++++++++++++++++++++
3 files changed, 172 insertions(+), 147 deletions(-)
create mode 100755 t/t5561-http-backend-noserver.sh
create mode 100755 t/t556x_common
diff --git a/t/t5560-http-backend.sh b/t/t5560-http-backend.sh
index 04a9896..dd844d3 100755
--- a/t/t5560-http-backend.sh
+++ b/t/t5560-http-backend.sh
@@ -12,16 +12,6 @@ LIB_HTTPD_PORT=${LIB_HTTPD_PORT-'5560'}
. "$TEST_DIRECTORY"/lib-httpd.sh
start_httpd
-find_file() {
- cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
- find $1 -type f |
- sed -e 1q
-}
-
-config() {
- git --git-dir="$HTTPD_DOCUMENT_ROOT_PATH/repo.git" config $1 $2
-}
-
GET() {
curl --include "$HTTPD_URL/$SMART/repo.git/$1" >out 2>/dev/null &&
tr '\015' Q <out |
@@ -52,143 +42,7 @@ log_div() {
echo "###" >>"$HTTPD_ROOT_PATH"/access.log
}
-test_expect_success 'setup repository' '
- echo content >file &&
- git add file &&
- git commit -m one &&
-
- mkdir "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
- (cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
- git --bare init &&
- : >objects/info/alternates &&
- : >objects/info/http-alternates
- ) &&
- git remote add public "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
- git push public master:master &&
-
- (cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
- git repack -a -d
- ) &&
-
- echo other >file &&
- git add file &&
- git commit -m two &&
- git push public master:master &&
-
- LOOSE_URL=$(find_file objects/??) &&
- PACK_URL=$(find_file objects/pack/*.pack) &&
- IDX_URL=$(find_file objects/pack/*.idx)
-'
-
-get_static_files() {
- GET HEAD "$1" &&
- GET info/refs "$1" &&
- GET objects/info/packs "$1" &&
- GET objects/info/alternates "$1" &&
- GET objects/info/http-alternates "$1" &&
- GET $LOOSE_URL "$1" &&
- GET $PACK_URL "$1" &&
- GET $IDX_URL "$1"
-}
-
-SMART=smart
-test_expect_success 'direct refs/heads/master not found' '
- log_div "refs/heads/master"
- GET refs/heads/master "404 Not Found"
-'
-test_expect_success 'static file is ok' '
- log_div "getanyfile default"
- get_static_files "200 OK"
-'
-SMART=smart_noexport
-test_expect_success 'no export by default' '
- log_div "no git-daemon-export-ok"
- get_static_files "404 Not Found"
-'
-test_expect_success 'export if git-daemon-export-ok' '
- log_div "git-daemon-export-ok"
- (cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
- touch git-daemon-export-ok
- ) &&
- get_static_files "200 OK"
-'
-SMART=smart
-test_expect_success 'static file if http.getanyfile true is ok' '
- log_div "getanyfile true"
- config http.getanyfile true &&
- get_static_files "200 OK"
-'
-test_expect_success 'static file if http.getanyfile false fails' '
- log_div "getanyfile false"
- config http.getanyfile false &&
- get_static_files "403 Forbidden"
-'
-
-test_expect_success 'http.uploadpack default enabled' '
- log_div "uploadpack default"
- GET info/refs?service=git-upload-pack "200 OK" &&
- POST git-upload-pack 0000 "200 OK"
-'
-test_expect_success 'http.uploadpack true' '
- log_div "uploadpack true"
- config http.uploadpack true &&
- GET info/refs?service=git-upload-pack "200 OK" &&
- POST git-upload-pack 0000 "200 OK"
-'
-test_expect_success 'http.uploadpack false' '
- log_div "uploadpack false"
- config http.uploadpack false &&
- GET info/refs?service=git-upload-pack "403 Forbidden" &&
- POST git-upload-pack 0000 "403 Forbidden"
-'
-
-test_expect_success 'http.receivepack default disabled' '
- log_div "receivepack default"
- GET info/refs?service=git-receive-pack "403 Forbidden" &&
- POST git-receive-pack 0000 "403 Forbidden"
-'
-test_expect_success 'http.receivepack true' '
- log_div "receivepack true"
- config http.receivepack true &&
- GET info/refs?service=git-receive-pack "200 OK" &&
- POST git-receive-pack 0000 "200 OK"
-'
-test_expect_success 'http.receivepack false' '
- log_div "receivepack false"
- config http.receivepack false &&
- GET info/refs?service=git-receive-pack "403 Forbidden" &&
- POST git-receive-pack 0000 "403 Forbidden"
-'
-run_backend() {
- REQUEST_METHOD=GET \
- GIT_PROJECT_ROOT="$HTTPD_DOCUMENT_ROOT_PATH" \
- PATH_INFO="$2" \
- git http-backend >act.out 2>act.err
-}
-
-path_info() {
- if test $1 = 0; then
- run_backend "$2"
- else
- test_must_fail run_backend "$2" &&
- echo "fatal: '$2': aliased" >exp.err &&
- test_cmp exp.err act.err
- fi
-}
-
-test_expect_success 'http-backend blocks bad PATH_INFO' '
- config http.getanyfile true &&
-
- run_backend 0 /repo.git/HEAD &&
-
- run_backend 1 /repo.git/../HEAD &&
- run_backend 1 /../etc/passwd &&
- run_backend 1 ../etc/passwd &&
- run_backend 1 /etc//passwd &&
- run_backend 1 /etc/./passwd &&
- run_backend 1 /etc/.../passwd &&
- run_backend 1 //domain/data.txt
-'
+. "$TEST_DIRECTORY"/t556x_common
cat >exp <<EOF
diff --git a/t/t5561-http-backend-noserver.sh b/t/t5561-http-backend-noserver.sh
new file mode 100755
index 0000000..501b328
--- /dev/null
+++ b/t/t5561-http-backend-noserver.sh
@@ -0,0 +1,52 @@
+#!/bin/sh
+
+test_description='test git-http-backend-noserver'
+. ./test-lib.sh
+
+HTTPD_DOCUMENT_ROOT_PATH="$TRASH_DIRECTORY"
+
+GET() {
+ return 0
+}
+
+POST() {
+ return 0
+}
+
+logdiv() {
+ return 0
+}
+
+. "$TEST_DIRECTORY"/t556x_common
+
+run_backend() {
+ REQUEST_METHOD=GET \
+ GIT_PROJECT_ROOT="$HTTPD_DOCUMENT_ROOT_PATH" \
+ PATH_INFO="$2" \
+ git http-backend >act.out 2>act.err
+}
+
+path_info() {
+ if test $1 = 0; then
+ run_backend "$2"
+ else
+ test_must_fail run_backend "$2" &&
+ echo "fatal: '$2': aliased" >exp.err &&
+ test_cmp exp.err act.err
+ fi
+}
+
+test_expect_success 'http-backend blocks bad PATH_INFO' '
+ config http.getanyfile true &&
+
+ run_backend 0 /repo.git/HEAD &&
+
+ run_backend 1 /repo.git/../HEAD &&
+ run_backend 1 /../etc/passwd &&
+ run_backend 1 ../etc/passwd &&
+ run_backend 1 /etc//passwd &&
+ run_backend 1 /etc/./passwd &&
+ run_backend 1 /etc/.../passwd &&
+ run_backend 1 //domain/data.txt
+'
+test_done
diff --git a/t/t556x_common b/t/t556x_common
new file mode 100755
index 0000000..1b4921c
--- /dev/null
+++ b/t/t556x_common
@@ -0,0 +1,119 @@
+#!/bin/sh
+
+find_file() {
+ cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
+ find $1 -type f |
+ sed -e 1q
+}
+
+config() {
+ git --git-dir="$HTTPD_DOCUMENT_ROOT_PATH/repo.git" config $1 $2
+}
+
+test_expect_success 'setup repository' '
+ echo content >file &&
+ git add file &&
+ git commit -m one &&
+
+ mkdir "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
+ (cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
+ git --bare init &&
+ : >objects/info/alternates &&
+ : >objects/info/http-alternates
+ ) &&
+ git remote add public "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
+ git push public master:master &&
+
+ (cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
+ git repack -a -d
+ ) &&
+
+ echo other >file &&
+ git add file &&
+ git commit -m two &&
+ git push public master:master &&
+
+ LOOSE_URL=$(find_file objects/??) &&
+ PACK_URL=$(find_file objects/pack/*.pack) &&
+ IDX_URL=$(find_file objects/pack/*.idx)
+'
+
+get_static_files() {
+ GET HEAD "$1" &&
+ GET info/refs "$1" &&
+ GET objects/info/packs "$1" &&
+ GET objects/info/alternates "$1" &&
+ GET objects/info/http-alternates "$1" &&
+ GET $LOOSE_URL "$1" &&
+ GET $PACK_URL "$1" &&
+ GET $IDX_URL "$1"
+}
+
+SMART=smart
+test_expect_success 'direct refs/heads/master not found' '
+ log_div "refs/heads/master"
+ GET refs/heads/master "404 Not Found"
+'
+test_expect_success 'static file is ok' '
+ log_div "getanyfile default"
+ get_static_files "200 OK"
+'
+SMART=smart_noexport
+test_expect_success 'no export by default' '
+ log_div "no git-daemon-export-ok"
+ get_static_files "404 Not Found"
+'
+test_expect_success 'export if git-daemon-export-ok' '
+ log_div "git-daemon-export-ok"
+ (cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
+ touch git-daemon-export-ok
+ ) &&
+ get_static_files "200 OK"
+'
+SMART=smart
+test_expect_success 'static file if http.getanyfile true is ok' '
+ log_div "getanyfile true"
+ config http.getanyfile true &&
+ get_static_files "200 OK"
+'
+test_expect_success 'static file if http.getanyfile false fails' '
+ log_div "getanyfile false"
+ config http.getanyfile false &&
+ get_static_files "403 Forbidden"
+'
+
+test_expect_success 'http.uploadpack default enabled' '
+ log_div "uploadpack default"
+ GET info/refs?service=git-upload-pack "200 OK" &&
+ POST git-upload-pack 0000 "200 OK"
+'
+test_expect_success 'http.uploadpack true' '
+ log_div "uploadpack true"
+ config http.uploadpack true &&
+ GET info/refs?service=git-upload-pack "200 OK" &&
+ POST git-upload-pack 0000 "200 OK"
+'
+test_expect_success 'http.uploadpack false' '
+ log_div "uploadpack false"
+ config http.uploadpack false &&
+ GET info/refs?service=git-upload-pack "403 Forbidden" &&
+ POST git-upload-pack 0000 "403 Forbidden"
+'
+
+test_expect_success 'http.receivepack default disabled' '
+ log_div "receivepack default"
+ GET info/refs?service=git-receive-pack "403 Forbidden" &&
+ POST git-receive-pack 0000 "403 Forbidden"
+'
+test_expect_success 'http.receivepack true' '
+ log_div "receivepack true"
+ config http.receivepack true &&
+ GET info/refs?service=git-receive-pack "200 OK" &&
+ POST git-receive-pack 0000 "200 OK"
+'
+test_expect_success 'http.receivepack false' '
+ log_div "receivepack false"
+ config http.receivepack false &&
+ GET info/refs?service=git-receive-pack "403 Forbidden" &&
+ POST git-receive-pack 0000 "403 Forbidden"
+'
--
1.6.6
^ permalink raw reply related
* Re: Minor bug in bash completion
From: Sylvain Rabot @ 2009-12-30 17:59 UTC (permalink / raw)
To: git
In-Reply-To: <20091230112222.GA493@neumann>
On Wed, 2009-12-30 at 12:22 +0100, SZEDER Gábor wrote:
> Hi Sylvain,
>
>
> On Tue, Dec 29, 2009 at 03:36:58PM +0100, Sylvain RABOT wrote:
> > I found a bug in the git bash completion.
> > It occurs when I press tab to complete branch name when I want to pull
> > from the origin.
> > Instead of completing the branch name it prompts me directly for my
> > password on the origin remote.
>
> I don't think it's a bug. The completion script should offer the
> currently available refs in the remote repository after a 'git pull
> <remote> <TAB>'. In order to do that it contacts the remote
> repository for the list of refs available there. Depending on the
> access method, it might need to authenticate, in your case via ssh.
> To silence the password prompts you should change your ssh
> configuration to use key-based authentication when logging in to the
> remote repository's server (just google for 'ssh login without
> password').
>
>
> Best,
> Gábor
Haaa,
I understand now, tough, I thought that the list of origin's branches
where stored somewhere in my local repository and that I needed to do a
"git remote update origin" to get the current origin branches list.
Thanks for your answer.
Regards.
--
Sylvain Rabot <sylvain@abstraction.fr>
^ permalink raw reply
* Re: [PATCH RFC 1/2] Smart-http tests: Break test t5560-http-backend into pieces
From: Tarmigan @ 2009-12-30 18:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O . Pearce, git
In-Reply-To: <7veimc2vq0.fsf@alter.siamese.dyndns.org>
On Wed, Dec 30, 2009 at 12:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Tarmigan Casebolt <tarmigan+git@gmail.com> writes:
>
>> This should introduce no functional change in the tests or the amount
>> of test coverage.
>>
>> Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
>
> This seems to crash rather badly with your own "Smart-http: check if
> repository is OK to export before serving it".
Yes, they were both separately based on 'master' a few days ago.
If you think the goal (more about that is in the commit log of 2/2) is
worthwhile, I am happy to rebase on top of pu and resend.
One reason it's labeled RFC is that I'm not very confident in my
ability to write portable shell script. It works for me with bash,
but I'm not completely confident that is would work on ksh or dash.
So it would be nice if you could specifically take a look at the new
POST() and GET() and see if you notice anything obviously wrong there.
Thanks,
Tarmigan
^ permalink raw reply
* Re: Minor bug in bash completion
From: Junio C Hamano @ 2009-12-30 18:00 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Sylvain RABOT, spearce, git
In-Reply-To: <20091230112222.GA493@neumann>
SZEDER Gábor <szeder@ira.uka.de> writes:
> On Tue, Dec 29, 2009 at 03:36:58PM +0100, Sylvain RABOT wrote:
>> I found a bug in the git bash completion.
>> It occurs when I press tab to complete branch name when I want to pull
>> from the origin.
>> Instead of completing the branch name it prompts me directly for my
>> password on the origin remote.
>
> I don't think it's a bug. The completion script should offer the
> currently available refs in the remote repository after a 'git pull
> <remote> <TAB>'. In order to do that it contacts the remote
> repository for the list of refs available there.
It is definitely a non-bug since the user _asked_ to complete and the
information necessary to do the job the user _asked_ to do is only
accessible over the network connection.
I however do think this is an annoyance when it happens to you by
accident. I wonder if it is worth to have a way for users to tell
completion to skip the ls-remote invocation (hence not getting branches
completed) depending on the type of remote.
^ permalink raw reply
* Re: [PATCH] reset: unbreak hard resets with GIT_WORK_TREE
From: Junio C Hamano @ 2009-12-30 17:54 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Fyn Fynn, Nguyen Thai Ngoc Duy, Nanako Shiraishi,
git
In-Reply-To: <20091230084702.GA19649@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Commit 952dfc6 tried to tighten the safety valves for doing
> a "reset --hard" in a bare repository or outside the work
> tree, but accidentally broke the case for GIT_WORK_TREE.
> This patch unbreaks it.
>
> Most git commands which need a work tree simply use
> NEED_WORK_TREE in git.c to die before they get to their
> cmd_* function. Reset, however, only needs a work tree in
> some cases, and so must handle the work tree itself. The
> error that 952dfc6 made was to simply forbid certain
> operations if the work tree was not set up; instead, we need
> to do the same thing that NEED_WORK_TREE does, which is to
> call setup_work_tree(). We no longer have to worry about dying
> in the non-worktree case, as setup_work_tree handles that
> for us.
Sounds very sane to me. Thanks.
^ permalink raw reply
* Re: [PATCH RFC 1/2] Smart-http tests: Break test t5560-http-backend into pieces
From: Junio C Hamano @ 2009-12-30 17:54 UTC (permalink / raw)
To: Tarmigan Casebolt; +Cc: Shawn O . Pearce, git
In-Reply-To: <1262037899-16786-1-git-send-email-tarmigan+git@gmail.com>
Tarmigan Casebolt <tarmigan+git@gmail.com> writes:
> This should introduce no functional change in the tests or the amount
> of test coverage.
>
> Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
This seems to crash rather badly with your own "Smart-http: check if
repository is OK to export before serving it".
^ permalink raw reply
* Re: [PATCH/resend] CVS Server: Support reading base and roots from environment
From: Phil Miller @ 2009-12-30 17:12 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20091230224108.6117@nanako3.lavabit.com>
On Wed, Dec 30, 2009 at 07:41, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Junio, could you tell us what happened to this thread?
>
> Phil Miller's patch to help gitosis installation. No response from
> git-cvsserver users.
I never resent with modifications as Junio requested. I've been busy
with some end-of-year close-out stuff, and actually wanted to
dramatically simplify part of the patch before the resend. I'll do
that shortly.
Since Gitosis wants to do repository-level access control before
running any Git commands, I figured out a CVSROOT format that would
let it do this. Given that, there's only one repository that an
invocation of git-cvsserver should be allowed to access, and so the
issue of "list separator" and so forth is moot. The resultant CVS
command line looks something like
cvs -d ":ext;CVS_SERVER=cvs
'/path/to/module':charmgit/path/to/module.git" co -d module
Note that I have had to modify Gitosis to make this, and various other
things, work. I had wanted to clean up my work before announcing it,
but if it would help you now, it is publicly available from github
now:
git://github.com/PhilMiller/gitosis.git
The documentation hasn't been updated, but the recent history makes as
least some usage clear. I'll send more details in a follow-up.
Phil
^ permalink raw reply
* [PATCH] builtin-config: add --path option doing ~ and ~user expansion.
From: Matthieu Moy @ 2009-12-30 16:51 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
395de250 (Expand ~ and ~user in core.excludesfile, commit.template)
introduced a C function git_config_pathname, doing ~/ and ~user/
expansion. This patch makes the feature available to scripts with 'git
config --get --path'.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/git-config.txt | 14 +++++++++++---
builtin-config.c | 20 +++++++++++++++++++-
t/t1300-repo-config.sh | 28 ++++++++++++++++++++++++++++
3 files changed, 58 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index f68b198..2632928 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -37,11 +37,12 @@ existing values that match the regexp are updated or unset. If
you want to handle the lines that do *not* match the regex, just
prepend a single exclamation mark in front (see also <<EXAMPLES>>).
-The type specifier can be either '--int' or '--bool', which will make
+The type specifier can be either '--int' or '--bool', to make
'git-config' ensure that the variable(s) are of the given type and
convert the value to the canonical form (simple decimal number for int,
-a "true" or "false" string for bool). If no type specifier is passed,
-no checks or transformations are performed on the value.
+a "true" or "false" string for bool), or '--path', which does some
+path expansion (see '--path' below). If no type specifier is passed, no
+checks or transformations are performed on the value.
The file-option can be one of '--system', '--global' or '--file'
which specify where the values will be read from or written to.
@@ -136,6 +137,13 @@ See also <<FILES>>.
'git-config' will ensure that the output matches the format of
either --bool or --int, as described above.
+--path::
+ 'git-config' will expand leading '{tilde}' to the value of
+ '$HOME', and '{tilde}user' to the home directory for the
+ specified user. This option has no effect when setting the
+ value (but you can use 'git config bla {tilde}/' from the
+ command line to let your shell do the expansion).
+
-z::
--null::
For all options that output values and/or keys, always
diff --git a/builtin-config.c b/builtin-config.c
index a2d656e..2e3ef91 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -45,6 +45,7 @@ static int end_null;
#define TYPE_BOOL (1<<0)
#define TYPE_INT (1<<1)
#define TYPE_BOOL_OR_INT (1<<2)
+#define TYPE_PATH (1<<3)
static struct option builtin_config_options[] = {
OPT_GROUP("Config file location"),
@@ -69,6 +70,7 @@ static struct option builtin_config_options[] = {
OPT_BIT(0, "bool", &types, "value is \"true\" or \"false\"", TYPE_BOOL),
OPT_BIT(0, "int", &types, "value is decimal number", TYPE_INT),
OPT_BIT(0, "bool-or-int", &types, "value is --bool or --int", TYPE_BOOL_OR_INT),
+ OPT_BIT(0, "path", &types, "value is a path (file or directory name)", TYPE_PATH),
OPT_GROUP("Other"),
OPT_BOOLEAN('z', "null", &end_null, "terminate values with NUL byte"),
OPT_END(),
@@ -94,6 +96,7 @@ static int show_config(const char *key_, const char *value_, void *cb)
{
char value[256];
const char *vptr = value;
+ int must_free_vptr = 0;
int dup_error = 0;
if (!use_key_regexp && strcmp(key_, key))
@@ -123,6 +126,9 @@ static int show_config(const char *key_, const char *value_, void *cb)
vptr = v ? "true" : "false";
else
sprintf(value, "%d", v);
+ } else if (types == TYPE_PATH) {
+ git_config_pathname(&vptr, key_, value_);
+ must_free_vptr = 1;
}
else
vptr = value_?value_:"";
@@ -133,6 +139,12 @@ static int show_config(const char *key_, const char *value_, void *cb)
}
else
printf("%s%c", vptr, term);
+ if (must_free_vptr)
+ /* If vptr must be freed, it's a pointer to a
+ * dynamically allocated buffer, it's safe to cast to
+ * const.
+ */
+ free((char *)vptr);
return 0;
}
@@ -215,7 +227,13 @@ static char *normalize_value(const char *key, const char *value)
if (!value)
return NULL;
- if (types == 0)
+ if (types == 0 || types == TYPE_PATH)
+ /*
+ * We don't do normalization for TYPE_PATH here: If
+ * the path is like ~/foobar/, we prefer to store
+ * "~/foobar/" in the config file, and to expand the ~
+ * when retrieving the value.
+ */
normalized = xstrdup(value);
else {
normalized = xmalloc(64);
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 83b7294..f89d7e9 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -683,6 +683,34 @@ test_expect_success 'set --bool-or-int' '
rm .git/config
+cat >expect <<\EOF
+[path]
+ home = ~/
+ normal = /dev/null
+ trailingtilde = foo~
+EOF
+
+test_expect_success 'set --path' '
+ git config --path path.home "~/" &&
+ git config --path path.normal "/dev/null" &&
+ git config --path path.trailingtilde "foo~" &&
+ test_cmp expect .git/config'
+
+cat >expect <<EOF
+$HOME/
+/dev/null
+foo~
+EOF
+
+test_expect_success 'get --path' '
+ git config --get --path path.home > result &&
+ git config --get --path path.normal >> result &&
+ git config --get --path path.trailingtilde >> result &&
+ test_cmp expect result
+'
+
+rm .git/config
+
git config quote.leading " test"
git config quote.ending "test "
git config quote.semicolon "test;test"
--
1.6.6.71.g392d.dirty
^ permalink raw reply related
* GNU patch: 2.6.1 release (mostly bugfixes)
From: Andreas Gruenbacher @ 2009-12-30 16:30 UTC (permalink / raw)
To: info-gnu; +Cc: git
Some glitches in release 2.6 of GNU patch made a new release 2.6.1 necessary,
available from:
ftp://ftp.gnu.org/gnu/patch/
The previous release was on 13 November. NEWS since then:
* Support for diff3(1) style merges which show the old, original, and new
lines of a conflict has been added (--merge=diff3). The default still is
the merge(1) format (--merge or --merge=merge).
* Bug and portability fixes.
The source code repository, a bug-patch@gnu.org mailing list archive, and the
project's bug tracker are available at:
http://savannah.gnu.org/projects/patch
Please email bugs or suggestions to <bug-patch@gnu.org>. Check the bug
tracker for a list of known issues.
Thanks,
Andreas
^ permalink raw reply
* [PATCH] fast-import: Document author/committer/tagger name is optional
From: Shawn O. Pearce @ 2009-12-30 15:03 UTC (permalink / raw)
To: David Reiss, Junio C Hamano; +Cc: git@vger.kernel.org
In-Reply-To: <4B3AED66.3030803@facebook.com>
The fast-import parser does not validate that the author, committer
or tagger name component contains both a name and an email address.
Therefore the name component has always been optional. Correct the
documentation to match the implementation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
David Reiss <dreiss@facebook.com> wrote:
> >> author <somename> 1261454209 +0000
> >> committer <somename> 1261454209 +0000
> > a foreign system where the data might not reasonably exist.
> But shouldn't there still be an extra space? One to separate "author"
> from the empty name, and one to separate the empty name from the email?
> If not, then I think this change should be made. (I couldn't find any
> authoritative documentation on what constitutes a valid commit object.)
Yes, we should do this.
Documentation/git-fast-import.txt | 6 +++---
fast-import.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 288032c..e6d364f 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -311,8 +311,8 @@ change to the project.
....
'commit' SP <ref> LF
mark?
- ('author' SP <name> SP LT <email> GT SP <when> LF)?
- 'committer' SP <name> SP LT <email> GT SP <when> LF
+ ('author' (SP <name>)? SP LT <email> GT SP <when> LF)?
+ 'committer' (SP <name>)? SP LT <email> GT SP <when> LF
data
('from' SP <committish> LF)?
('merge' SP <committish> LF)?
@@ -657,7 +657,7 @@ lightweight (non-annotated) tags see the `reset` command below.
....
'tag' SP <name> LF
'from' SP <committish> LF
- 'tagger' SP <name> SP LT <email> GT SP <when> LF
+ 'tagger' (SP <name>)? SP LT <email> GT SP <when> LF
data
....
diff --git a/fast-import.c b/fast-import.c
index dd3c99d..cd87049 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -19,8 +19,8 @@ Format of STDIN stream:
new_commit ::= 'commit' sp ref_str lf
mark?
- ('author' sp name sp '<' email '>' sp when lf)?
- 'committer' sp name sp '<' email '>' sp when lf
+ ('author' (sp name)? sp '<' email '>' sp when lf)?
+ 'committer' (sp name)? sp '<' email '>' sp when lf
commit_msg
('from' sp committish lf)?
('merge' sp committish lf)*
@@ -47,7 +47,7 @@ Format of STDIN stream:
new_tag ::= 'tag' sp tag_str lf
'from' sp committish lf
- ('tagger' sp name sp '<' email '>' sp when lf)?
+ ('tagger' (sp name)? sp '<' email '>' sp when lf)?
tag_msg;
tag_msg ::= data;
--
1.6.6.307.gba67
--
Shawn.
^ permalink raw reply related
* Re: [PATCH] bash completion: add space between branch name and status flags
From: Shawn O. Pearce @ 2009-12-30 14:57 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git, Roman Fietze
In-Reply-To: <20091230224129.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Junio, could you tell us what happened to this thread?
>
> In response to a patch from Roman Fietze to outline a better way
> to do it. Nothing happened.
Junio responded with a suggestion on how to improve the patch when
GIT_PS1_SHOWDIRTYSTATE was not set, but Roman Fietze didn't send
a revised patch, so it got dropped.
Here is the revised patch, Junio, still think its a good idea?
--8<--
From: Roman Fietze <roman.fietze@telemotive.de>
Subject: [PATCH] bash completion: add space between branch name and status flags
Improve the readability of the bash prompt by adding a space between
the branch name and the status flags (dirty, stash, untracked).
Signed-off-by: Roman Fietze <roman.fietze@telemotive.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/completion/git-completion.bash | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index fbfa5f2..3c8b6df 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -163,10 +163,12 @@ __git_ps1 ()
fi
fi
+ local f="$w$i$s$u"
+ f="${f:+ $f}$r"
if [ -n "${1-}" ]; then
- printf "$1" "$c${b##refs/heads/}$w$i$s$u$r"
+ printf "$1" "$c${b##refs/heads/}$f"
else
- printf " (%s)" "$c${b##refs/heads/}$w$i$s$u$r"
+ printf " (%s)" "$c${b##refs/heads/}$f"
fi
fi
}
--
1.6.6.307.gba67
--
Shawn.
^ permalink raw reply related
* [PATCH] SubmittingPatches: hints to know the status of a submitted patch.
From: Matthieu Moy @ 2009-12-30 14:51 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
"What happened to my patch" is pretty much a FAQ on the Git mailing list,
it deserves a few paragraphs in SubmittingPatches...
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
(I had already sent this patch as a draft RFC, admitedly rather well
hidden within another thread. Let's retry a bit more explicitly ;-) )
Documentation/SubmittingPatches | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 76fc84d..c686f86 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -280,6 +280,20 @@ people play with it without having to pick up and apply the patch to
their trees themselves.
------------------------------------------------
+Know the status of your patch after submission
+
+* You can use Git itself to find out when your patch is merged in
+ master. 'git pull --rebase' will automatically skip already-applied
+ patches, and will let you know. This works only if you rebase on top
+ of the branch in which your patch has been merged (i.e. it will not
+ tell you if your patch is merged in pu if you rebase on top of
+ master).
+
+* Read the git mailing list, the maintainer regularly posts messages
+ entitled "What's cooking in git.git" and "What's in git.git" giving
+ the status of various proposed changes.
+
+------------------------------------------------
MUA specific hints
Some of patches I receive or pick up from the list share common
--
1.6.6.71.gcc720.dirty
^ permalink raw reply related
* [PATCH] branch: die explicitly why when calling "git branch [-a|-r] branchname".
From: Matthieu Moy @ 2009-12-30 14:45 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
The -a and -r options used to be silently ignored in such a command.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
builtin-branch.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index c87e63b..8aef2bb 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -638,10 +638,13 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
rename_branch(head, argv[0], rename > 1);
else if (rename && (argc == 2))
rename_branch(argv[0], argv[1], rename > 1);
- else if (argc <= 2)
+ else if (argc <= 2) {
+ if (kinds != REF_LOCAL_BRANCH) {
+ die("-a and -r options to 'git branch' do not make sense with a branch name");
+ }
create_branch(head, argv[0], (argc == 2) ? argv[1] : head,
force_create, reflog, track);
- else
+ } else
usage_with_options(builtin_branch_usage, options);
return 0;
--
1.6.6.71.gcc720.dirty
^ permalink raw reply related
* Re: [PATCH v2] Let core.excludesfile default to ~/.gitexcludes.
From: Matthieu Moy @ 2009-12-30 14:31 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git
In-Reply-To: <20091230224135.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, could you tell us what happened to this thread?
I'm not Junio, but I can try ...
Setting a default for core.excludesfile implies that changing it later
is hard. In particular, _if_ we chose one day to move from multiple
$HOME/.gitsomething files to $HOME/something-else/multiple-files
($XDG_CONFIG_HOME and $HOME/.gitglobal/{config,excludes,...} have been
suggested, as well as a $GIT_HOME variable), then the transition is
made harder by having a default.
So, while I think having a default is good, chosing the default
shouldn't be taken lightly.
I personally like the idea of a user config _directory_ with multiple
files in it, but I'm not clear on exactly what it should be, how the
transition plan would be, ...
So, I dropped the patch until we get closer to a consensus on what the
default value should be.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] grep: do not do external grep on skip-worktree entries
From: Nguyễn Thái Ngọc Duy @ 2009-12-30 14:11 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
Skip-worktree entries are not on disk. There is no reason to call
external grep in such cases.
A trace message is also added to aid debugging external grep cases.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin-grep.c | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index d582232..d49c637 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -488,17 +488,34 @@ static int grep_cache(struct grep_opt *opt, const char **paths, int cached,
read_cache();
#if !NO_EXTERNAL_GREP
+ if (cached)
+ external_grep_allowed = 0;
+ if (external_grep_allowed) {
+ for (nr = 0; nr < active_nr; nr++) {
+ struct cache_entry *ce = active_cache[nr];
+ if (!S_ISREG(ce->ce_mode))
+ continue;
+ if (!pathspec_matches(paths, ce->name, opt->max_depth))
+ continue;
+ if (ce_skip_worktree(ce)) {
+ external_grep_allowed = 0;
+ break;
+ }
+ }
+ }
/*
* Use the external "grep" command for the case where
* we grep through the checked-out files. It tends to
* be a lot more optimized
*/
- if (!cached && external_grep_allowed) {
+ if (external_grep_allowed) {
hit = external_grep(opt, paths, cached);
if (hit >= 0)
return hit;
hit = 0;
}
+ else
+ trace_printf("grep: external grep not used\n");
#endif
for (nr = 0; nr < active_nr; nr++) {
--
1.6.6.315.g1a406
^ permalink raw reply related
* Re: [PATCH] git-update-index: report(...) now flushes stdout after printing the report line
From: Sebastian Thiel @ 2009-12-30 13:56 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20091119T221732-624@post.gmane.org>
I'd like to add that since version 1.6.5, non-tty's do not receive any progress
information anymore. The patch causing this says it wants to, in short words,
unify the push and fetch handling regarding the way progress messages are sent.
Now third-party wrappers, such as git-python, are unable to provide any progress
information anymore for possibly lengthy operations.
This is why I clearly recommend to add some kind of a "progress-force" flag that
turns progress messages on again for send-pack and receive-pack.
^ permalink raw reply
* Re: [PATCH 1/6] run-command: add "use shell" option
From: Erik Faye-Lund @ 2009-12-30 13:55 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <20091230105316.GA22959@coredump.intra.peff.net>
On Wed, Dec 30, 2009 at 11:53 AM, Jeff King <peff@peff.net> wrote:
> Many callsites run "sh -c $CMD" to run $CMD. We can make it
> a little simpler for them by factoring out the munging of
> argv.
>
> For simple cases with no arguments, this doesn't help much, but:
>
> 1. For cases with arguments, we save the caller from
> having to build the appropriate shell snippet.
>
> 2. We can later optimize to avoid the shell when
> there are no metacharacters in the program.
>
Nice. This could be helpful if we ever decide not to depend on a
sh-compatible shell on Windows (since one isn't included by default no
Windows, and installing msys/cygwin has some compatibility-issues with
previous installations).
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [Updated PATCH 1/2] Report exec errors from run-command
From: Erik Faye-Lund @ 2009-12-30 13:47 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1262170338-11574-2-git-send-email-ilari.liusvaara@elisanet.fi>
On Wed, Dec 30, 2009 at 11:52 AM, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
> +static inline void force_close(int fd)
> +{
> + while (close(fd) < 0 && errno != EBADF)
> + ; /* No-op */
> +}
> +
According to http://linux.die.net/man/2/close, close can set errno to
EBADF, EINTR, or EIO. Currently, you're retrying on EINTR and EIO.
When we get EIO, are you sure it makes sense to retry? I'd imagine
that error would most likely just repeat itself, leading to an
infinite loop. How about "while (close(fd) < 0 && errno == EINTR)"
instead? I've seen other functions (like xread in wrapper.c) only
retry on those errors that it expects. In xreads case, it's not
retrying on EIO.
Perhaps it's OK still, since force_close() is only used on pipes. I
don't know if closing a pipe can generate EIO or not.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH] bash completion: add space between branch name and status flags
From: Nanako Shiraishi @ 2009-12-30 13:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git, Roman Fietze
In-Reply-To: <7v4oopxeuf.fsf@alter.siamese.dyndns.org>
Junio, could you tell us what happened to this thread?
In response to a patch from Roman Fietze to outline a better way
to do it. Nothing happened.
^ permalink raw reply
* Re: [PATCH v2] Let core.excludesfile default to ~/.gitexcludes.
From: Nanako Shiraishi @ 2009-12-30 13:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, Matthieu Moy, git
In-Reply-To: <1258840832-22130-1-git-send-email-Matthieu.Moy@imag.fr>
Junio, could you tell us what happened to this thread?
^ permalink raw reply
* Re: [PATCH] git-update-index: report(...) now flushes stdout after printing the report line
From: Nanako Shiraishi @ 2009-12-30 13:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sebastian Thiel, git
In-Reply-To: <loom.20091119T221732-624@post.gmane.org>
Junio, could you tell us what happened to this thread?
^ permalink raw reply
* Re: [PATCH v2] cvsserver: make the output of 'update' more compatible with cvs.
From: Nanako Shiraishi @ 2009-12-30 13:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sergei Organov, git
In-Reply-To: <87bpibdonj.fsf@osv.gnss.ru>
Junio, could you tell us what happened to this thread?
^ permalink raw reply
* Re: [PATCH] t9700-perl-git.sh: Fix a test failure on Cygwin
From: Nanako Shiraishi @ 2009-12-30 13:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramsay Jones, GIT Mailing-list
In-Reply-To: <4B059150.5050303@ramsay1.demon.co.uk>
Junio, could you tell us what happened to this thread?
^ permalink raw reply
* Re: [PATCH/resend] CVS Server: Support reading base and roots from environment
From: Nanako Shiraishi @ 2009-12-30 13:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Phil Miller
In-Reply-To: <7vocmwvmvr.fsf@alter.siamese.dyndns.org>
Junio, could you tell us what happened to this thread?
Phil Miller's patch to help gitosis installation. No response from
git-cvsserver users.
^ permalink raw reply
* Re: [PATCH v3] builtin-push: add --delete as syntactic sugar for :foo
From: Sverre Rabbelier @ 2009-12-30 12:14 UTC (permalink / raw)
To: Jan Krüger; +Cc: Junio C Hamano, Nanako Shiraishi, Git ML
In-Reply-To: <20091230105244.67f5969e@perceptron>
Heya,
On Wed, Dec 30, 2009 at 03:52, Jan Krüger <jk@jk.gs> wrote:
>> So if Jan or Sverre want to resurrect the topic, I am all for it.
>
> Alrighty. I assume by (3) you meant that it should be possible to use
> something like "push there --delete tag v1.0.0". Version 3 of the patch
> adds this, and it also includes updated tests and (brief) documentation.
Thanks for picking this up.
--
Cheers,
Sverre Rabbelier
^ 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