* Re: [PATCH 1/2] git-svn, perl/Git.pm: add central method for prompting passwords honoring GIT_ASKPASS and SSH_ASKPASS
From: Sven Strickroth @ 2012-01-04 19:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Jakub Narebski
In-Reply-To: <7vmxa3pa6e.fsf@alter.siamese.dyndns.org>
Am 04.01.2012 19:58 schrieb Junio C Hamano:
> Depending on how widespread such implementations of Perl are, a patch to
> fix other uses of chomps might deserve to be on the maintenance track
> independent from this patch series. I seem to find many hits to:
>
> $ git grep -e 'chomp *([^)@]*='
>
> already in our codebase.
I'm not sure if this is a general chomp problem. I think that this is
more related to a variable which is accessed after a readfailure on STDIN.
Reported to msys team.
--
Best regards,
Sven Strickroth
ClamAV, a GPL anti-virus toolkit http://www.clamav.net
PGP key id F5A9D4C4 @ any key-server
^ permalink raw reply
* Re: How to deal with historic tar-balls
From: Philip Oakley @ 2012-01-04 20:04 UTC (permalink / raw)
To: Dirk Süsserott; +Cc: Tomas Carnecky, nn6eumtr, Git List
In-Reply-To: <4F01F6D2.8020005@dirk.my1.cc>
Many thanks - That explanation works for me. I just hadn't seen the
association.
Philip
From: "Dirk Süsserott" <newsletter@dirk.my1.cc>: Monday, January 02, 2012
6:26 PM
> Am 02.01.2012 11:07 schrieb Philip Oakley:
>>> From: "Tomas Carnecky" <tom@dbservice.com> : Sunday, January 01, 2012
>>> 12:27 AM
>>>> On 12/31/11 8:04 PM, nn6eumtr wrote:
>>>>> I have a number of older projects that I want to bring into a git
>>>>> repository. They predate a lot of the popular scm systems, so they are
>>>>> primarily a collection of tarballs today.
>>>> There is a script which will import sources from multiple tarballs,
>>>> creating a commit with the contents of each tarball. It's in the git
>>>> repository under contrib/fast-import/import-tars.perl.
>>> I wasn't aware of those scripts. I'll be having a look at the zip import
>>> script for my needs.
>>>
>>>> tom
>>> Philip
>>>
>> I had a look at the script but Python isn't part of the Msysgit install,
>> so the example wouldn't run.
>>
>> Also I couldn't see how the "fast_import.write(" method was being
>> created - my ignorance of Python? Otherwise I could look at scripting it.
>>
>> Philip
>
> Philip,
>
> I'm not a Python guy, but I think fast_import.write() writes sth. to
> whatever the popen() call in line 24 returned:
>
> fast_import = popen('git fast-import --quiet', 'w')
>
> I guess it returns a filehandle and 'git fast-import' reads its data
> from stdin. My guess is, that -- instead of writing to that pipe -- you
> could as well write everything to a temporary file and finally call
>
> git fast-import < $tempfile
>
> But that's only a guess.
>
> Dirk
>>
^ permalink raw reply
* Re: [PATCH 1/2] daemon: add tests
From: Junio C Hamano @ 2012-01-04 20:13 UTC (permalink / raw)
To: Clemens Buchacher
Cc: git, Jonathan Nieder, Jeff King, Erik Faye-Lund, Ilari Liusvaara,
Nguyễn Thái Ngọc Duy
In-Reply-To: <7vy5tnpcuw.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Clemens Buchacher <drizzd@aon.at> writes:
> ...
>>> >> + # kill git-daemon child of git
>>> >> + say >&3 "Stopping git daemon ..."
>>> >> + pkill -P "$DAEMON_PID"
>>>
>>> How portable is this one (I usually do not trust use of pkill anywhere)?
>>
>> I read that it is supposed to be more portable than skill or killall.
>> But I have no way to research this. I have implemented a workaround
>> using only 'ps' and 'kill' in [PATCH 3/6] avoid use of pkill.
>
> Yuck, that patch looks even uglier X-<.
>
> Do you really need to kill the children but not the daemon?
To reduce round-trip cost, here is what I'll queue for now.
-- >8 --
From: Clemens Buchacher <drizzd@aon.at>
Date: Wed, 4 Jan 2012 16:55:35 +0100
Subject: [PATCH] daemon: add tests
The semantics of the git daemon tests are similar to the http transport
tests. In fact, they are only a slightly modified copy of t5550, plus the
newly added remote error tests.
All git-daemon tests will be skipped unless the environment variable
GIT_TEST_GIT_DAEMON is set.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/lib-git-daemon.sh | 56 ++++++++++++++++++
t/t5570-git-daemon.sh | 148 +++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 204 insertions(+), 0 deletions(-)
create mode 100644 t/lib-git-daemon.sh
create mode 100755 t/t5570-git-daemon.sh
diff --git a/t/lib-git-daemon.sh b/t/lib-git-daemon.sh
new file mode 100644
index 0000000..c0ff9e2
--- /dev/null
+++ b/t/lib-git-daemon.sh
@@ -0,0 +1,56 @@
+#!/bin/sh
+
+if test -z "$GIT_TEST_GIT_DAEMON"
+then
+ skip_all="git-daemon testing disabled (define GIT_TEST_GIT_DAEMON to enable)"
+ test_done
+fi
+
+LIB_GIT_DAEMON_PORT=${LIB_GIT_DAEMON_PORT-'8121'}
+
+GIT_DAEMON_PID=
+GIT_DAEMON_DOCUMENT_ROOT_PATH="$PWD"/repo
+GIT_DAEMON_URL=git://127.0.0.1:$LIB_GIT_DAEMON_PORT
+
+start_git_daemon() {
+ if test -n "$GIT_DAEMON_PID"
+ then
+ error "start_git_daemon already called"
+ fi
+
+ mkdir -p "$GIT_DAEMON_DOCUMENT_ROOT_PATH"
+
+ trap 'code=$?; stop_git_daemon; (exit $code); die' EXIT
+
+ say >&3 "Starting git daemon ..."
+ git daemon --listen=127.0.0.1 --port="$LIB_GIT_DAEMON_PORT" \
+ --reuseaddr --verbose \
+ --base-path="$GIT_DAEMON_DOCUMENT_ROOT_PATH" \
+ "$@" "$GIT_DAEMON_DOCUMENT_ROOT_PATH" \
+ >&3 2>&4 &
+ GIT_DAEMON_PID=$!
+}
+
+stop_git_daemon() {
+ if test -z "$GIT_DAEMON_PID"
+ then
+ return
+ fi
+
+ trap 'die' EXIT
+
+ # kill git-daemon child of git
+ say >&3 "Stopping git daemon ..."
+ pkill -P "$GIT_DAEMON_PID"
+ wait "$GIT_DAEMON_PID"
+ ret=$?
+ #
+ # We signal TERM=15 to the child and expect the parent to
+ # exit with 143 = 128+15.
+ #
+ if test $ret -ne 143
+ then
+ error "git daemon exited with status: $ret"
+ fi
+ GIT_DAEMON_PID=
+}
diff --git a/t/t5570-git-daemon.sh b/t/t5570-git-daemon.sh
new file mode 100755
index 0000000..7cbc999
--- /dev/null
+++ b/t/t5570-git-daemon.sh
@@ -0,0 +1,148 @@
+#!/bin/sh
+
+test_description='test fetching over git protocol'
+. ./test-lib.sh
+
+LIB_GIT_DAEMON_PORT=${LIB_GIT_DAEMON_PORT-5570}
+. "$TEST_DIRECTORY"/lib-git-daemon.sh
+start_git_daemon
+
+test_expect_success 'setup repository' '
+ echo content >file &&
+ git add file &&
+ git commit -m one
+'
+
+test_expect_success 'create git-accessible bare repository' '
+ mkdir "$GIT_DAEMON_DOCUMENT_ROOT_PATH/repo.git" &&
+ (cd "$GIT_DAEMON_DOCUMENT_ROOT_PATH/repo.git" &&
+ git --bare init &&
+ : >git-daemon-export-ok
+ ) &&
+ git remote add public "$GIT_DAEMON_DOCUMENT_ROOT_PATH/repo.git" &&
+ git push public master:master
+'
+
+test_expect_success 'clone git repository' '
+ git clone "$GIT_DAEMON_URL/repo.git" clone &&
+ test_cmp file clone/file
+'
+
+test_expect_success 'fetch changes via git protocol' '
+ echo content >>file &&
+ git commit -a -m two &&
+ git push public &&
+ (cd clone && git pull) &&
+ test_cmp file clone/file
+'
+
+test_expect_failure 'remote detects correct HEAD' '
+ git push public master:other &&
+ (cd clone &&
+ git remote set-head -d origin &&
+ git remote set-head -a origin &&
+ git symbolic-ref refs/remotes/origin/HEAD > output &&
+ echo refs/remotes/origin/master > expect &&
+ test_cmp expect output
+ )
+'
+
+test_expect_success 'prepare pack objects' '
+ cp -R "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo.git "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_pack.git &&
+ (cd "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_pack.git &&
+ git --bare repack -a -d
+ )
+'
+
+test_expect_success 'fetch notices corrupt pack' '
+ cp -R "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_pack.git "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_bad1.git &&
+ (cd "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_bad1.git &&
+ p=`ls objects/pack/pack-*.pack` &&
+ chmod u+w $p &&
+ printf %0256d 0 | dd of=$p bs=256 count=1 seek=1 conv=notrunc
+ ) &&
+ mkdir repo_bad1.git &&
+ (cd repo_bad1.git &&
+ git --bare init &&
+ test_must_fail git --bare fetch "$GIT_DAEMON_URL/repo_bad1.git" &&
+ test 0 = `ls objects/pack/pack-*.pack | wc -l`
+ )
+'
+
+test_expect_success 'fetch notices corrupt idx' '
+ cp -R "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_pack.git "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_bad2.git &&
+ (cd "$GIT_DAEMON_DOCUMENT_ROOT_PATH"/repo_bad2.git &&
+ p=`ls objects/pack/pack-*.idx` &&
+ chmod u+w $p &&
+ printf %0256d 0 | dd of=$p bs=256 count=1 seek=1 conv=notrunc
+ ) &&
+ mkdir repo_bad2.git &&
+ (cd repo_bad2.git &&
+ git --bare init &&
+ test_must_fail git --bare fetch "$GIT_DAEMON_URL/repo_bad2.git" &&
+ test 0 = `ls objects/pack | wc -l`
+ )
+'
+
+test_remote_error()
+{
+ do_export=YesPlease
+ while test $# -gt 0
+ do
+ case $1 in
+ -x)
+ shift
+ chmod -x "$GIT_DAEMON_DOCUMENT_ROOT_PATH/repo.git"
+ ;;
+ -n)
+ shift
+ do_export=
+ ;;
+ *)
+ break
+ esac
+ done
+
+ if test $# -ne 3
+ then
+ error "invalid number of arguments"
+ fi
+
+ cmd=$1
+ repo=$2
+ msg=$3
+
+ if test -x "$GIT_DAEMON_DOCUMENT_ROOT_PATH/$repo"
+ then
+ if test -n "$do_export"
+ then
+ : >"$GIT_DAEMON_DOCUMENT_ROOT_PATH/$repo/git-daemon-export-ok"
+ else
+ rm -f "$GIT_DAEMON_DOCUMENT_ROOT_PATH/$repo/git-daemon-export-ok"
+ fi
+ fi
+
+ test_must_fail git "$cmd" "$GIT_DAEMON_URL/$repo" 2>output &&
+ echo "fatal: remote error: $msg: /$repo" >expect &&
+ test_cmp expect output
+ ret=$?
+ chmod +x "$GIT_DAEMON_DOCUMENT_ROOT_PATH/repo.git"
+ (exit $ret)
+}
+
+msg="access denied or repository not exported"
+test_expect_success 'clone non-existent' "test_remote_error clone nowhere.git '$msg'"
+test_expect_success 'push disabled' "test_remote_error push repo.git '$msg'"
+test_expect_success 'read access denied' "test_remote_error -x fetch repo.git '$msg'"
+test_expect_success 'not exported' "test_remote_error -n fetch repo.git '$msg'"
+
+stop_git_daemon
+start_git_daemon --informative-errors
+
+test_expect_success 'clone non-existent' "test_remote_error clone nowhere.git 'no such repository'"
+test_expect_success 'push disabled' "test_remote_error push repo.git 'service not enabled'"
+test_expect_success 'read access denied' "test_remote_error -x fetch repo.git 'no such repository'"
+test_expect_success 'not exported' "test_remote_error -n fetch repo.git 'repository not exported'"
+
+stop_git_daemon
+test_done
--
1.7.8.2.340.gd18f0f
^ permalink raw reply related
* Re: [PATCH 1/2] daemon: add tests
From: Clemens Buchacher @ 2012-01-04 20:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jonathan Nieder, Jeff King, Erik Faye-Lund, Ilari Liusvaara,
Nguyễn Thái Ngọc Duy
In-Reply-To: <7vy5tnpcuw.fsf@alter.siamese.dyndns.org>
On Wed, Jan 04, 2012 at 10:00:07AM -0800, Junio C Hamano wrote:
>
> >> >> + # kill git-daemon child of git
> >> >> + say >&3 "Stopping git daemon ..."
> >> >> + pkill -P "$DAEMON_PID"
> >>
> >> How portable is this one (I usually do not trust use of pkill anywhere)?
> >
> > I read that it is supposed to be more portable than skill or killall.
> > But I have no way to research this. I have implemented a workaround
> > using only 'ps' and 'kill' in [PATCH 3/6] avoid use of pkill.
>
> Yuck, that patch looks even uglier X-<.
>
> Do you really need to kill the children but not the daemon?
If I kill just the parent "git daemon" command, then the actual
git-daemon (started by run_command) will be left behind.
^ permalink raw reply
* git log --since --until
From: Hilco Wijbenga @ 2012-01-04 21:46 UTC (permalink / raw)
To: Git Users
Hi all,
I need to write sort of a report listing what we worked on (month by
month) over the last year. Yippie. ;-)
Luckily most of the information I can get from our Git logs but I
noticed some "anomalies". The quotes are there because I do understand
(or I think I do anyway) why those "anomalies" are there.
As an example, I ran (on master)
git log --since="01-Dec-2011" --until="31-Dec-2011"
The returned list of commits also included a few from November. I'm
guessing that's because --since and --until simply determine a start
commit and an end commit in master and any commit that falls in that
range is included, whether its actual commit date is in the originally
specified date range or not.
Is there a way to just get the commits made in December? (I can
manually go through the list, of course, [and that's probably what
I'll do] but playing with Git is more fun than writing a report. ;-) )
Cheers,
Hilco
^ permalink raw reply
* [PATCH 1/3] verify_signed_buffer: fix stale comment
From: Junio C Hamano @ 2012-01-04 22:10 UTC (permalink / raw)
To: git
In-Reply-To: <1325715058-11984-1-git-send-email-gitster@pobox.com>
The function used to take an integer flag to specify where the output
should go, but these days we supply a strbuf to receive it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
gpg-interface.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/gpg-interface.c b/gpg-interface.c
index 18630ff..09ab64a 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -95,10 +95,7 @@ int sign_buffer(struct strbuf *buffer, struct strbuf *signature, const char *sig
/*
* Run "gpg" to see if the payload matches the detached signature.
- * gpg_output_to tells where the output from "gpg" should go:
- * < 0: /dev/null
- * = 0: standard error of the calling process
- * > 0: the specified file descriptor
+ * gpg_output, when set, receives the diagnostic output from GPG.
*/
int verify_signed_buffer(const char *payload, size_t payload_size,
const char *signature, size_t signature_size,
--
1.7.8.2.340.gd18f0f
^ permalink raw reply related
* [PATCH 2/3] log-tree.c: small refactor in show_signature()
From: Junio C Hamano @ 2012-01-04 22:10 UTC (permalink / raw)
To: git
In-Reply-To: <1325715058-11984-1-git-send-email-gitster@pobox.com>
The next patch needs to show the result of signature verification on a
mergetag extended header in a way similar to how embedded signature for
the commit object itself is shown. Separate out the logic to go through
the message lines and show them in the "error" color (highlighted) or the
"correct" color (dim).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
log-tree.c | 28 ++++++++++++++++------------
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 142ba51..005c5a5 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -404,13 +404,27 @@ void log_write_email_headers(struct rev_info *opt, struct commit *commit,
*extra_headers_p = extra_headers;
}
+static void show_sig_lines(struct rev_info *opt, int status, const char *bol)
+{
+ const char *color, *reset, *eol;
+
+ color = diff_get_color_opt(&opt->diffopt,
+ status ? DIFF_WHITESPACE : DIFF_FRAGINFO);
+ reset = diff_get_color_opt(&opt->diffopt, DIFF_RESET);
+ while (*bol) {
+ eol = strchrnul(bol, '\n');
+ printf("%s%.*s%s%s", color, (int)(eol - bol), bol, reset,
+ *eol ? "\n" : "");
+ bol = (*eol) ? (eol + 1) : eol;
+ }
+}
+
static void show_signature(struct rev_info *opt, struct commit *commit)
{
struct strbuf payload = STRBUF_INIT;
struct strbuf signature = STRBUF_INIT;
struct strbuf gpg_output = STRBUF_INIT;
int status;
- const char *color, *reset, *bol, *eol;
if (parse_signed_commit(commit->object.sha1, &payload, &signature) <= 0)
goto out;
@@ -421,17 +435,7 @@ static void show_signature(struct rev_info *opt, struct commit *commit)
if (status && !gpg_output.len)
strbuf_addstr(&gpg_output, "No signature\n");
- color = diff_get_color_opt(&opt->diffopt,
- status ? DIFF_WHITESPACE : DIFF_FRAGINFO);
- reset = diff_get_color_opt(&opt->diffopt, DIFF_RESET);
-
- bol = gpg_output.buf;
- while (*bol) {
- eol = strchrnul(bol, '\n');
- printf("%s%.*s%s%s", color, (int)(eol - bol), bol, reset,
- *eol ? "\n" : "");
- bol = (*eol) ? (eol + 1) : eol;
- }
+ show_sig_lines(opt, status, gpg_output.buf);
out:
strbuf_release(&gpg_output);
--
1.7.8.2.340.gd18f0f
^ permalink raw reply related
* [PATCH 0/3] More on pulling signed tags
From: Junio C Hamano @ 2012-01-04 22:10 UTC (permalink / raw)
To: git
This extends on the earlier topic to pull and merge signed tags. So far,
we did record them for later auditing, but did not have an easy way to
perform the auditing, other than manually extracting the information from
the commit object.
Applies on top of the merge between the current 'master' and the
'jc/signed-commit' topic still in 'next', as the latter topic already has
necessary infrastructure to hook into the "log" machinery to show the
signatures embedded in commit objects with the "--show-signature" option.
Help on adding tests, docs and tying loose ends are very much appreciated.
A sample workflow with the command may look like this:
$ git checkout v1.7.8^0
$ git pull $elsewhere v1.7.8.2
$ git show -s --show-signature
commit e00ee29c760ae27c177ec16adb8c94b85909f464
parent #2, tagged 'v1.7.8.2'
gpg: Signature made Wed 28 Dec 2011 12:03:39 PM PST using RSA key ID 96AFE6CB
gpg: Good signature from "Junio C Hamano <gitster@pobox.com>"
gpg: aka "Junio C Hamano <junio@pobox.com>"
gpg: aka "Junio C Hamano <jch@google.com>"
Merge: 406da78 f3f778d
Author: Junio C Hamano <gitster@pobox.com>
Date: Wed Jan 4 14:05:03 2012 -0800
Merge tag 'v1.7.8.2' of ../git into HEAD
Git 1.7.8.2
$ git commit -S --amend --no-edit
commit df409f0d0b1f3f521dd0fd2baf6ecf01495c0191
gpg: Signature made Wed 04 Jan 2012 02:05:26 PM PST using RSA key ID 96AFE6CB
gpg: Good signature from "Junio C Hamano <gitster@pobox.com>"
gpg: aka "Junio C Hamano <junio@pobox.com>"
gpg: aka "Junio C Hamano <jch@google.com>"
parent #2, tagged 'v1.7.8.2'
gpg: Signature made Wed 28 Dec 2011 12:03:39 PM PST using RSA key ID 96AFE6CB
gpg: Good signature from "Junio C Hamano <gitster@pobox.com>"
gpg: aka "Junio C Hamano <junio@pobox.com>"
gpg: aka "Junio C Hamano <jch@google.com>"
Merge: 406da78 f3f778d
Author: Junio C Hamano <gitster@pobox.com>
Date: Wed Jan 4 14:05:03 2012 -0800
Merge tag 'v1.7.8.2' of ../git into HEAD
Git 1.7.8.2
Junio C Hamano (3):
verify_signed_buffer: fix stale comment
log-tree.c: small refactor in show_signature()
log-tree: show mergetag in log --show-signature output
gpg-interface.c | 5 +--
log-tree.c | 104 ++++++++++++++++++++++++++++++++++++++++++++++++-------
2 files changed, 92 insertions(+), 17 deletions(-)
--
1.7.8.2.340.gd18f0f
^ permalink raw reply
* [PATCH 3/3] log-tree: show mergetag in log --show-signature output
From: Junio C Hamano @ 2012-01-04 22:10 UTC (permalink / raw)
To: git
In-Reply-To: <1325715058-11984-1-git-send-email-gitster@pobox.com>
A commit object that merges a signed tag records the "mergetag" extended
header. Check the validity of the GPG signature on it, and show it in a
way similar to how "gpgsig" extended header is shown.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
log-tree.c | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 75 insertions(+), 1 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 005c5a5..b87dd53 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -443,6 +443,78 @@ static void show_signature(struct rev_info *opt, struct commit *commit)
strbuf_release(&signature);
}
+static int which_parent(const unsigned char *sha1, const struct commit *commit)
+{
+ int nth;
+ const struct commit_list *parent;
+
+ for (nth = 0, parent = commit->parents; parent; parent = parent->next) {
+ if (!hashcmp(parent->item->object.sha1, sha1))
+ return nth;
+ nth++;
+ }
+ return -1;
+}
+
+static void show_one_mergetag(struct rev_info *opt,
+ struct commit_extra_header *extra,
+ struct commit *commit)
+{
+ unsigned char sha1[20];
+ struct tag *tag;
+ struct strbuf verify_message;
+ int status, nth;
+ size_t payload_size, gpg_message_offset;
+
+ hash_sha1_file(extra->value, extra->len, typename(OBJ_TAG), sha1);
+ tag = lookup_tag(sha1);
+ if (!tag)
+ return; /* error message already given */
+
+ strbuf_init(&verify_message, 256);
+ if (parse_tag_buffer(tag, extra->value, extra->len))
+ strbuf_addstr(&verify_message, "malformed mergetag\n");
+ else if ((nth = which_parent(tag->tagged->sha1, commit)) < 0)
+ strbuf_addf(&verify_message, "tag %s names a non-parent %s\n",
+ tag->tag, tag->tagged->sha1);
+ else
+ strbuf_addf(&verify_message,
+ "parent #%d, tagged '%s'\n", nth + 1, tag->tag);
+ gpg_message_offset = verify_message.len;
+
+ payload_size = parse_signature(extra->value, extra->len);
+ if ((extra->len <= payload_size) ||
+ (verify_signed_buffer(extra->value, payload_size,
+ extra->value + payload_size,
+ extra->len - payload_size,
+ &verify_message) &&
+ verify_message.len <= gpg_message_offset)) {
+ strbuf_addstr(&verify_message, "No signature\n");
+ status = -1;
+ }
+ else if (strstr(verify_message.buf + gpg_message_offset,
+ ": Good signature from "))
+ status = 0;
+ else
+ status = -1;
+
+ show_sig_lines(opt, status, verify_message.buf);
+ strbuf_release(&verify_message);
+}
+
+static void show_mergetag(struct rev_info *opt, struct commit *commit)
+{
+ struct commit_extra_header *extra, *to_free;
+
+ to_free = read_commit_extra_headers(commit);
+ for (extra = to_free; extra; extra = extra->next) {
+ if (strcmp(extra->key, "mergetag"))
+ continue; /* not a merge tag */
+ show_one_mergetag(opt, extra, commit);
+ }
+ free_commit_extra_headers(to_free);
+}
+
void show_log(struct rev_info *opt)
{
struct strbuf msgbuf = STRBUF_INIT;
@@ -554,8 +626,10 @@ void show_log(struct rev_info *opt)
}
}
- if (opt->show_signature)
+ if (opt->show_signature) {
show_signature(opt, commit);
+ show_mergetag(opt, commit);
+ }
if (!commit->buffer)
return;
--
1.7.8.2.340.gd18f0f
^ permalink raw reply related
* Re: [PATCH 1/2] daemon: add tests
From: Junio C Hamano @ 2012-01-04 22:15 UTC (permalink / raw)
To: Clemens Buchacher
Cc: git, Jonathan Nieder, Jeff King, Erik Faye-Lund, Ilari Liusvaara,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20120104204017.GC27567@ecki.lan>
Clemens Buchacher <drizzd@aon.at> writes:
> On Wed, Jan 04, 2012 at 10:00:07AM -0800, Junio C Hamano wrote:
>>
>> >> >> + # kill git-daemon child of git
>> >> >> + say >&3 "Stopping git daemon ..."
>> >> >> + pkill -P "$DAEMON_PID"
>> >>
>> >> How portable is this one (I usually do not trust use of pkill anywhere)?
>> >
>> > I read that it is supposed to be more portable than skill or killall.
>> > But I have no way to research this. I have implemented a workaround
>> > using only 'ps' and 'kill' in [PATCH 3/6] avoid use of pkill.
>>
>> Yuck, that patch looks even uglier X-<.
>>
>> Do you really need to kill the children but not the daemon?
>
> If I kill just the parent "git daemon" command, then the actual
> git-daemon (started by run_command) will be left behind.
Sounds like we would be better off with a new "--foreground" option other
daemon-ish projects seem to have?
^ permalink raw reply
* Re: git log --since --until
From: Junio C Hamano @ 2012-01-04 22:16 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Git Users
In-Reply-To: <CAE1pOi30FL+hRSqr3XRNgvOr4yBcTsbTpiNXpxJ=CN1Q=JVo3w@mail.gmail.com>
Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
> git log --since="01-Dec-2011" --until="31-Dec-2011"
>
> The returned list of commits also included a few from November.
These limits act on committer dates. Are you by any chance looking at
author dates instead?
^ permalink raw reply
* Re: [PATCH 1/2] daemon: add tests
From: Jeff King @ 2012-01-04 22:26 UTC (permalink / raw)
To: Junio C Hamano
Cc: Clemens Buchacher, git, Jonathan Nieder, Erik Faye-Lund,
Ilari Liusvaara, Nguyễn Thái Ngọc Duy
In-Reply-To: <7vaa63p11t.fsf@alter.siamese.dyndns.org>
On Wed, Jan 04, 2012 at 02:15:10PM -0800, Junio C Hamano wrote:
> >> Do you really need to kill the children but not the daemon?
> >
> > If I kill just the parent "git daemon" command, then the actual
> > git-daemon (started by run_command) will be left behind.
>
> Sounds like we would be better off with a new "--foreground" option other
> daemon-ish projects seem to have?
Isn't that usually for "don't background yourself"? AFAIK, git-daemon
stays in the foreground and only forks to handle each connection. So
can't we just kill the main process, and any running cruft will
eventually die as connections are closed?
Or is the problem the git wrapper itself, which doesn't kill its
subprocess when it dies (which IMHO is a bug which we might want to
fix)? In that case, couldn't we just use --pid-file to save the actual
daemon pid, and then kill using that?
As a side note, it looks like we just start the daemon with "git daemon
&". Doesn't that create a race condition with the tests which
immediately try to access it (i.e., the first test may run before the
daemon actually opens the socket)?
-Peff
^ permalink raw reply
* Re: git log --since --until
From: Hilco Wijbenga @ 2012-01-04 22:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Users
In-Reply-To: <7v62grp0z4.fsf@alter.siamese.dyndns.org>
On 4 January 2012 14:16, Junio C Hamano <gitster@pobox.com> wrote:
> Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
>
>> git log --since="01-Dec-2011" --until="31-Dec-2011"
>>
>> The returned list of commits also included a few from November.
>
> These limits act on committer dates. Are you by any chance looking at
> author dates instead?
I had to look that up. :-) Yes, I'm apparently looking at (and for)
author dates. I don't really care when the commit was merged into
master (that's the committer date, right?), I want to know when the
work was done.
I didn't really see any useful switches for git log in this regard but
then the author date seems to be additional data without special
meaning to Git.
^ permalink raw reply
* Re: git log --since --until
From: Junio C Hamano @ 2012-01-04 22:58 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Git Users
In-Reply-To: <CAE1pOi2vi8WHFNg2+NJCWnQ_atnCTRKXyBDJJpA8GM6nHmj6HQ@mail.gmail.com>
Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
> ... the author date seems to be additional data without special
> meaning to Git.
That is exactly correct. The author date is merely for human consumption.
^ permalink raw reply
* Re: [PATCH] Do not fetch tags on new shallow clones
From: Junio C Hamano @ 2012-01-04 23:59 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1325676922-6995-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> This could also be applied for normal clones. But I don't think
> there are many use cases for it, enough to deserve new --no-tags
> option.
Correct.
> We should also fetch a single branch, but because branches are
> usually less crowded and stay close the tip, they do not produce too
> many extra objects. Let's leave it until somebody yells up.
Probably this is needed.
> We should also fetch tags that reference to downloaded objects.
I do not think this has much merit. The usual tag-following rules AFAIK
assumes that if you have the commit C then you ought to have all the
ancestors of C, which does not apply at all for the shallow hack to begin
with, and if you make the rule apply for the shallow hack, you would end
up slurping the objects that are needed only for ancient versions, which
would defeat the objective of this patch, no?
It also is my understanding that the shallow hack is almost always used
with a depth of one, not a range, like "git archive | tar xf -", so if
anything, I would say a single-branch cloning has much higher priority
than following tags.
Will queue on 'pu'. Thanks.
^ permalink raw reply
* Re: [PATCH 0/3] More on pulling signed tags
From: Junio C Hamano @ 2012-01-05 0:10 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <1325715058-11984-1-git-send-email-gitster@pobox.com>
Junio C Hamano <gitster@pobox.com> writes:
> A sample workflow with the command may look like this:
> ...
> $ git show -s --show-signature
With this, in the Linux kernel repository, you could do this.
$ git show -s --show-signature 2240a7bb47
commit 2240a7bb479c38434bd636da9ce6afbd3f49447a
parent #2, tagged 'tytso-for-linus-20111214'
gpg: Signature made Wed 14 Dec 2011 11:15:13 AM PST using RSA key ID C11804F0
gpg: Good signature from "Theodore Ts'o <tytso@mit.edu>"
gpg: aka "Theodore Ts'o <tytso@debian.org>"
gpg: aka "Theodore Ts'o <tytso@google.com>"
Merge: 30aaca4 5a0dc73
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed Dec 14 18:25:58 2011 -0800
Merge tag 'tytso-for-linus-20111214' of git://git.kernel.org/pub/scm/linu...
* tag 'tytso-for-linus-20111214' of git://git.kernel.org/pub/scm/linux/ke...
8< snip 8<
.. using the new signed tag merge of git that now verifies the gpg
signature automatically. Yay. The branchname was just 'dev', which is
prettier. I'll tell Ted to use nicer tag names for future cases.
We might want to reword "parent #2", by the way. The code was designed to
apply even to an Octopus, but I suspect 99.9% of the mergetag will be on
the second parent of a two-parent commit. You will never see "parent #1"
(i.e. direct parent you pulled into) unless you hand-craft the merge
commit object, and you are not likely to create an Octopus that pulls
multiple signed tags into one commit.
^ permalink raw reply
* Re: [PATCH 1/2] daemon: add tests
From: Clemens Buchacher @ 2012-01-05 0:07 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, git, Jonathan Nieder, Erik Faye-Lund,
Ilari Liusvaara, Nguyễn Thái Ngọc Duy
In-Reply-To: <20120104222649.GA14727@sigill.intra.peff.net>
On Wed, Jan 04, 2012 at 05:26:49PM -0500, Jeff King wrote:
>
> Or is the problem the git wrapper itself, which doesn't kill its
> subprocess when it dies (which IMHO is a bug which we might want to
> fix)? In that case, couldn't we just use --pid-file to save the actual
> daemon pid, and then kill using that?
Or like this. Doesn't work with multiple children. I have yet to
check if we have those anywhere.
diff --git a/run-command.c b/run-command.c
index 1c51043..0c105e6 100644
--- a/run-command.c
+++ b/run-command.c
@@ -65,6 +65,22 @@ static int execv_shell_cmd(const char **argv)
#ifndef WIN32
static int child_err = 2;
static int child_notifier = -1;
+static struct child_process *current_cmd;
+
+static void kill_current_cmd(int signo)
+{
+ signal(signo, SIG_DFL);
+
+ if (current_cmd) {
+ if (current_cmd->pid) {
+ /* forward signal to the child process */
+ kill(current_cmd->pid, signo);
+ } else {
+ /* trigger the default signal handler */
+ raise(signo);
+ }
+ }
+}
static void notify_parent(void)
{
@@ -201,6 +217,9 @@ fail_pipe:
if (pipe(notify_pipe))
notify_pipe[0] = notify_pipe[1] = -1;
+ current_cmd = cmd;
+ signal(SIGTERM, kill_current_cmd);
+
cmd->pid = fork();
if (!cmd->pid) {
/*
diff --git a/t/lib-daemon.sh b/t/lib-daemon.sh
index b2ffd54..c1c41ee 100644
--- a/t/lib-daemon.sh
+++ b/t/lib-daemon.sh
@@ -41,8 +41,8 @@ stop_daemon() {
# kill git-daemon child of git
say >&3 "Stopping git daemon ..."
- pkill -P "$DAEMON_PID"
- wait "$DAEMON_PID"
+ kill "$DAEMON_PID"
+ wait "$DAEMON_PID" >&3 2>&4
ret=$?
#
# We signal TERM=15 to the child and expect the parent to
> As a side note, it looks like we just start the daemon with "git daemon
> &". Doesn't that create a race condition with the tests which
> immediately try to access it (i.e., the first test may run before the
> daemon actually opens the socket)?
That's correct. How would I fix that? Try connecting and sleep in a
loop until ready or timeout? Will look into that.
^ permalink raw reply related
* Re: [PATCH 0/3] More on pulling signed tags
From: Junio C Hamano @ 2012-01-05 0:22 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <7vsjjvnh4e.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> We might want to reword "parent #2", by the way. The code was designed to
> apply even to an Octopus, but I suspect 99.9% of the mergetag will be on
> the second parent of a two-parent commit. You will never see "parent #1"
> (i.e. direct parent you pulled into) unless you hand-craft the merge
> commit object, and you are not likely to create an Octopus that pulls
> multiple signed tags into one commit.
... and this is a fix-up patch on top of the series. With this, the output
becomes like this:
commit 2240a7bb479c38434bd636da9ce6afbd3f49447a
merged tag 'tytso-for-linus-20111214'
gpg: Signature made Wed 14 Dec 2011 11:15:13 AM PST using RSA key ID C11804F0
gpg: Good signature from "Theodore Ts'o <tytso@mit.edu>"
gpg: aka "Theodore Ts'o <tytso@debian.org>"
gpg: aka "Theodore Ts'o <tytso@google.com>"
Merge: 30aaca4 5a0dc73
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed Dec 14 18:25:58 2011 -0800
Merge tag 'tytso-for-linus-20111214' of git://git.kernel.org/pub/scm/l...
* tag 'tytso-for-linus-20111214' of git://git.kernel.org/pub/scm/linux...
ext4: handle EOF correctly in ext4_bio_write_page()
...
log-tree.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index b87dd53..37510da 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -456,6 +456,13 @@ static int which_parent(const unsigned char *sha1, const struct commit *commit)
return -1;
}
+static int is_common_merge(const struct commit *commit)
+{
+ return (commit->parents
+ && commit->parents->next
+ && !commit->parents->next->next);
+}
+
static void show_one_mergetag(struct rev_info *opt,
struct commit_extra_header *extra,
struct commit *commit)
@@ -474,6 +481,11 @@ static void show_one_mergetag(struct rev_info *opt,
strbuf_init(&verify_message, 256);
if (parse_tag_buffer(tag, extra->value, extra->len))
strbuf_addstr(&verify_message, "malformed mergetag\n");
+ else if (is_common_merge(commit) &&
+ !hashcmp(tag->tagged->sha1,
+ commit->parents->next->item->object.sha1))
+ strbuf_addf(&verify_message,
+ "merged tag '%s'\n", tag->tag);
else if ((nth = which_parent(tag->tagged->sha1, commit)) < 0)
strbuf_addf(&verify_message, "tag %s names a non-parent %s\n",
tag->tag, tag->tagged->sha1);
^ permalink raw reply related
* Re: [PATCH 1/2] daemon: add tests
From: Junio C Hamano @ 2012-01-05 0:24 UTC (permalink / raw)
To: Clemens Buchacher
Cc: Jeff King, git, Jonathan Nieder, Erik Faye-Lund, Ilari Liusvaara,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20120105000713.GA24220@ecki.lan>
Clemens Buchacher <drizzd@aon.at> writes:
> On Wed, Jan 04, 2012 at 05:26:49PM -0500, Jeff King wrote:
>>
>> Or is the problem the git wrapper itself, which doesn't kill its
>> subprocess when it dies (which IMHO is a bug which we might want to
>> fix)? In that case, couldn't we just use --pid-file to save the actual
>> daemon pid, and then kill using that?
>
> Or like this. Doesn't work with multiple children. I have yet to
> check if we have those anywhere.
Hmm, don't we have them in the same process group or something, though?
Can't we kill them as a whole?
^ permalink raw reply
* Re: [PATCH 0/3] More on pulling signed tags
From: Linus Torvalds @ 2012-01-05 0:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobujngl3.fsf@alter.siamese.dyndns.org>
On Wed, Jan 4, 2012 at 4:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> ... and this is a fix-up patch on top of the series. With this, the output
> becomes like this:
Looking good, this is very useful. The hacks to extract the signatures
with 'git cat-file' were pretty ugly.
This is also nice for the case where the person doing the merge
doesn't yet have the pgp key something was signed with, so when you do
the "git pull", you get the "unknown key" thing instead of a "good
signature" message in the editor buffer.
It *used* to be the case that you had to abort the merge, fetch the
key, and re-pull in order to verify the key.
Now you can just say "ok, I'll commit the merge" and finish up, then
fetch the key, do "git show --show-signature", and if it doesn't show
up as good (which would be very rare) you can then 'git reset'
instead. Which while less anal, is a lot more convenient.
Linus
^ permalink raw reply
* Re: [PATCH 1/2] daemon: add tests
From: Clemens Buchacher @ 2012-01-05 0:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, git, Jonathan Nieder, Erik Faye-Lund, Ilari Liusvaara,
Nguyễn Thái Ngọc Duy
In-Reply-To: <7vk457ngi0.fsf@alter.siamese.dyndns.org>
On Wed, Jan 04, 2012 at 04:24:23PM -0800, Junio C Hamano wrote:
> Clemens Buchacher <drizzd@aon.at> writes:
>
> > On Wed, Jan 04, 2012 at 05:26:49PM -0500, Jeff King wrote:
> >>
> >> Or is the problem the git wrapper itself, which doesn't kill its
> >> subprocess when it dies (which IMHO is a bug which we might want to
> >> fix)? In that case, couldn't we just use --pid-file to save the actual
> >> daemon pid, and then kill using that?
> >
> > Or like this. Doesn't work with multiple children. I have yet to
> > check if we have those anywhere.
>
> Hmm, don't we have them in the same process group or something, though?
> Can't we kill them as a whole?
I tried that, but it seems that the test script itself is in the
same process group.
^ permalink raw reply
* Re: [PATCH 1/2] daemon: add tests
From: Jakub Narebski @ 2012-01-05 2:24 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Clemens Buchacher, git, Jonathan Nieder,
Erik Faye-Lund, Ilari Liusvaara,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20120104222649.GA14727@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> As a side note, it looks like we just start the daemon with "git daemon
> &". Doesn't that create a race condition with the tests which
> immediately try to access it (i.e., the first test may run before the
> daemon actually opens the socket)?
Hmmm... perhaps the trick that git-instaweb does for "plackup" web
server would be of use here, waiting for socket to be ready?
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH 1/2] daemon: add tests
From: Jeff King @ 2012-01-05 2:51 UTC (permalink / raw)
To: Jakub Narebski
Cc: Junio C Hamano, Clemens Buchacher, git, Jonathan Nieder,
Erik Faye-Lund, Ilari Liusvaara,
Nguyễn Thái Ngọc Duy
In-Reply-To: <m3vcoqevjm.fsf@localhost.localdomain>
On Wed, Jan 04, 2012 at 06:24:16PM -0800, Jakub Narebski wrote:
> Jeff King <peff@peff.net> writes:
>
> > As a side note, it looks like we just start the daemon with "git daemon
> > &". Doesn't that create a race condition with the tests which
> > immediately try to access it (i.e., the first test may run before the
> > daemon actually opens the socket)?
>
> Hmmm... perhaps the trick that git-instaweb does for "plackup" web
> server would be of use here, waiting for socket to be ready?
It looks like it busy loops, which is kind of ugly.
The credential-cache helper has a similar problem. It wants to kick off
a daemon if one is not already running, and then connect to it. So the
daemon does:
printf("ok\n");
fclose(stdout);
when it has set up the socket, and the client does:
r = read_in_full(daemon.out, buf, sizeof(buf));
if (r < 0)
die_errno("unable to read result code from cache daemon");
if (r != 3 || memcmp(buf, "ok\n", 3))
die("cache daemon did not start: %.*s", r, buf);
/* now we can connect over the socket */
We could probably add a "--notify-when-ready" option to git-daemon to
do something similar.
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] daemon: add tests
From: Jeff King @ 2012-01-05 2:55 UTC (permalink / raw)
To: Clemens Buchacher
Cc: Junio C Hamano, git, Jonathan Nieder, Erik Faye-Lund,
Ilari Liusvaara, Nguyễn Thái Ngọc Duy
In-Reply-To: <20120105000713.GA24220@ecki.lan>
On Thu, Jan 05, 2012 at 01:07:13AM +0100, Clemens Buchacher wrote:
> On Wed, Jan 04, 2012 at 05:26:49PM -0500, Jeff King wrote:
> >
> > Or is the problem the git wrapper itself, which doesn't kill its
> > subprocess when it dies (which IMHO is a bug which we might want to
> > fix)? In that case, couldn't we just use --pid-file to save the actual
> > daemon pid, and then kill using that?
>
> Or like this. Doesn't work with multiple children. I have yet to
> check if we have those anywhere.
It so happens that I have just the patch you need. I've been meaning to
go over it again and submit it:
run-command: optionally kill children on exit
https://github.com/peff/git/commit/5523d7ebf2a0386c9c61d7bfbc21375041df4989
The original use case was to help with this:
https://github.com/peff/git/commit/79bf3f232f89c3e2f5284a3b7b71a667be8825d1
> > As a side note, it looks like we just start the daemon with "git daemon
> > &". Doesn't that create a race condition with the tests which
> > immediately try to access it (i.e., the first test may run before the
> > daemon actually opens the socket)?
>
> That's correct. How would I fix that? Try connecting and sleep in a
> loop until ready or timeout? Will look into that.
Your choices are basically busy-waiting, or convincing the daemon to
send a signal when it's ready to serve. I like the latter, but it does
mean adding a small amount of code to git-daemon.
-Peff
^ permalink raw reply
* Re: [PATCH] Do not fetch tags on new shallow clones
From: Shawn Pearce @ 2012-01-05 3:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyễn Thái Ngọc, git
In-Reply-To: <7vwr97nho7.fsf@alter.siamese.dyndns.org>
2012/1/4 Junio C Hamano <gitster@pobox.com>:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>> We should also fetch tags that reference to downloaded objects.
>
> I do not think this has much merit.
I disagree. Its useful because cloning a branch immediately after it
has been tagged for a release should have `git describe` provide back
the name of the release from the tag (assuming of course no new
commits were made since the tag).
> The usual tag-following rules AFAIK
> assumes that if you have the commit C then you ought to have all the
> ancestors of C, which does not apply at all for the shallow hack to begin
> with, and if you make the rule apply for the shallow hack, you would end
> up slurping the objects that are needed only for ancient versions, which
> would defeat the objective of this patch, no?
We aren't talking about fetching the ancient history tags. We are
talking about fetching a tag that *directly* points at one of the
commits we did download the complete tree of.
> It also is my understanding that the shallow hack is almost always used
> with a depth of one, not a range, like "git archive | tar xf -", so if
> anything, I would say a single-branch cloning has much higher priority
> than following tags.
I think I agree with you on priority of work effort. But I lack time
to make good on that by writing the code myself. :-)
^ 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