On Thu, Mar 28, 2013 at 07:40:51AM +0700, Duy Nguyen wrote:
Maybe we could do it in index-pack to save some (wall) time. I haven't
tried but I think it might work. The problem is to make sure the pack
contains objects for all sha1 references in the pack. By that
description, we don't need to
From: Thomas Rast tr...@inf.ethz.ch
I had a quick-and-dirty edit to t/valgrind/valgrind.sh in my trees
while we did the index-pack investigation. This small series is the
proper way of achieving the same.
Thomas Rast (3):
t/README: --valgrind already implies -v
tests: parameterize
From: Thomas Rast tr...@inf.ethz.ch
This was missed in 3da9365 (Tests: let --valgrind imply --verbose and
--tee, 2009-02-04).
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
t/README | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/t/README b/t/README
index
From: Thomas Rast tr...@inf.ethz.ch
Running tests under helgrind and DRD recently proved useful in
tracking down thread interaction issues. This can unfortunately not
be done through GIT_VALGRIND_OPTIONS because any tool other than
memcheck would complain about unknown options.
Let --valgrind
From: Thomas Rast tr...@inf.ethz.ch
With --valgrind=memcheck-fast, the tests run under memcheck but
without the autodetected --track-origins. If you just run valgrind to
see *if* there is any memory issue with your program, the extra
information is not needed, and it comes at a roughly 30% hit
Sebastian Götte ja...@physik.tu-berlin.de writes:
When --verify-signatures is specified, abort the merge in case a good
GPG signature from an untrusted key is encountered.
[...]
+test_expect_success GPG 'merge commit with untrusted signature with
verification' '
We tell valgrind to return 126 if it notices that something is wrong,
but we did not actually handle this in test_must_fail, leading to
false negatives. Catch and report it.
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
Just noticed this issue when tracking down the failure in t7612. It
Maybe. But I would worry somewhat about sites which provide a useless
and verbose text/plain message. Ideally an x-git-error-message would be
no more than few lines, suitable for the error message of a terminal
program. I would not want a site-branded Your page cannot be found.
Here's a
On 03/31/2013 10:32 AM, Thomas Rast wrote:
Sebastian Götte ja...@physik.tu-berlin.de writes:
When --verify-signatures is specified, abort the merge in case a good
GPG signature from an untrusted key is encountered.
[...]
+test_expect_success GPG 'merge commit with untrusted signature with
My investigation in lowering connectivity check cost in git-clone [1]
led me to try 'index-pack --strict' code. Without calling fsck_object(),
--strict seems to be cheaper than check_everything_connected() while
accomplishing the same thing (imo).
The first patch is a bug fix running git-clone
index-pack --strict looks up and follows parent commits. If shallow
information is not ready by the time index-pack is run, index-pack may
be lead to non-existent objects. Make fetch-pack save shallow file to
disk before invoking index-pack.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/index-pack.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index ef62124..fdac7c7 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -735,8 +735,7 @@
--not-so-strict only checks if all links from objects in the pack
point to real objects (either in current repo, or from the pack
itself). It's like check_everything_connected() except that:
- it does not follow DAG in order
- it can detect incomplete object islands
- it seems to be faster
This replaces check_everything_connected() with --not-so-strict, which
accomplishes the same thing and is generally cheaper.
This also forces connectivity check on git clone.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/fetch.c | 6 --
Sebastian Götte ja...@physik.tu-berlin.de wrote:
On 03/31/2013 10:32 AM, Thomas Rast wrote:
+ test_must_fail git merge --ff-only --verify-signatures
side-untrusted 2mergeerror
+ test_i18ngrep from an untrusted key mergeerror
+'
This test gives me the following:
==26527== Conditional
On 03/31/2013 01:38 PM, Thomas Rast wrote:
Sebastian Götte ja...@physik.tu-berlin.de wrote:
On 03/31/2013 10:32 AM, Thomas Rast wrote:
+ test_must_fail git merge --ff-only --verify-signatures
side-untrusted 2mergeerror
+ test_i18ngrep from an untrusted key mergeerror
+'
This test
Sebastian Götte ja...@physik.tu-berlin.de wrote:
expecting success:
test_must_fail git merge --ff-only --verify-signatures side-untrusted
2mergeerror
test_i18ngrep has a good, untrusted GPG signature mergeerror
==1430== Conditional jump or move depends on uninitialised value(s)
On 03/31/2013 02:16 PM, Thomas Rast wrote:
Sebastian Götte ja...@physik.tu-berlin.de wrote:
expecting success:
test_must_fail git merge --ff-only --verify-signatures side-untrusted
2mergeerror
test_i18ngrep has a good, untrusted GPG signature mergeerror
==1430== Conditional jump
On Sun, Mar 31, 2013 at 02:27:20PM +0200, Sebastian Götte wrote:
On 03/31/2013 02:16 PM, Thomas Rast wrote:
Sebastian Götte ja...@physik.tu-berlin.de wrote:
expecting success:
test_must_fail git merge --ff-only --verify-signatures side-untrusted
2mergeerror
test_i18ngrep has
On 03/31/2013 03:33 PM, John Keeping wrote:
It looks like the found pointer has wandered off the end of the
string. In the test case here, the gpg_status is:
-- 8 --
[GNUPG:] SIG_ID rzX3GbdzQyxB4Jdm1uD0CzL4B4Y 2013-03-31 1364735152
[GNUPG:] GOODSIG 61092E85B7227189 Eris Discordia
Signed-off-by: Sebastian Götte ja...@physik-pool.tu-berlin.de
---
commit.c| 59 +
commit.h| 10 +++
gpg-interface.h | 11 +++
pretty.c| 91 +
4 files changed, 93
Signed-off-by: Sebastian Götte ja...@physik-pool.tu-berlin.de
---
commit.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/commit.c b/commit.c
index eb645af..eda7f90 100644
--- a/commit.c
+++ b/commit.c
@@ -1027,8 +1027,8 @@ static struct {
char
When --verify-signatures is specified on the command-line of git-merge
or git-pull, check whether the commits being merged have good gpg
signatures and abort the merge in case they do not. This allows e.g.
auto-deployment from untrusted repo hosts.
Signed-off-by: Sebastian Götte
When --verify-signatures is specified, abort the merge in case a good
GPG signature from an untrusted key is encountered.
Signed-off-by: Sebastian Götte ja...@physik-pool.tu-berlin.de
---
Documentation/merge-options.txt| 4 ++--
builtin/merge.c| 2 ++
commit.c
Expand %G? in pretty format strings to 'N' in case of no GPG signature
and 'U' in case of a good but untrusted GPG signature in addition to
the previous 'G'ood and 'B'ad. This eases writing anyting parsing
git-log output.
Signed-off-by: Sebastian Götte ja...@physik-pool.tu-berlin.de
---
On Sun, Mar 31, 2013 at 04:32:52PM +0200, Sebastian Götte wrote:
Signed-off-by: Sebastian Götte ja...@physik-pool.tu-berlin.de
---
commit.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/commit.c b/commit.c
index eb645af..eda7f90 100644
---
On Sun, Mar 31, 2013 at 04:33:57PM +0200, Sebastian Götte wrote:
When --verify-signatures is specified, abort the merge in case a good
GPG signature from an untrusted key is encountered.
Signed-off-by: Sebastian Götte ja...@physik-pool.tu-berlin.de
---
Documentation/merge-options.txt|
John Keeping j...@keeping.me.uk writes:
On Sun, Mar 31, 2013 at 04:33:57PM +0200, Sebastian Götte wrote:
diff --git a/commit.c b/commit.c
index eda7f90..bb2d9ad 100644
--- a/commit.c
+++ b/commit.c
@@ -1029,6 +1029,8 @@ static struct {
} sigcheck_gpg_status[] = {
{ 'G', [GNUPG:]
On 03/31/2013 05:03 PM, Thomas Rast wrote:
John Keeping j...@keeping.me.uk writes:
On Sun, Mar 31, 2013 at 04:33:57PM +0200, Sebastian Götte wrote:
diff --git a/commit.c b/commit.c
index eda7f90..bb2d9ad 100644
--- a/commit.c
+++ b/commit.c
@@ -1029,6 +1029,8 @@ static struct {
}
On Sun, Mar 31, 2013 at 05:03:44PM +0200, Thomas Rast wrote:
John Keeping j...@keeping.me.uk writes:
On Sun, Mar 31, 2013 at 04:33:57PM +0200, Sebastian Götte wrote:
diff --git a/commit.c b/commit.c
index eda7f90..bb2d9ad 100644
--- a/commit.c
+++ b/commit.c
@@ -1029,6 +1029,8 @@
Sebastian Götte ja...@physik.tu-berlin.de writes:
On 03/31/2013 05:03 PM, Thomas Rast wrote:
} sigcheck_gpg_status[] = {
{ 'G', [GNUPG:] GOODSIG },
{ 'B', [GNUPG:] BADSIG },
+ { 'U', [GNUPG:] TRUST_NEVER },
+ { 'U', [GNUPG:] TRUST_UNDEFINED },
[...]
And furthermore, to use an
On 03/31/2013 04:41 PM, John Keeping wrote: On Sun, Mar 31, 2013 at 04:32:52PM
+0200, Sebastian Götte wrote:
+/* Iterate over all search strings */
for (i = 0; i ARRAY_SIZE(sigcheck_gpg_status); i++) {
-const char *found = strstr(buf, sigcheck_gpg_status[i].check);
-
Signed-off-by: Sebastian Götte ja...@physik-pool.tu-berlin.de
---
commit.c| 59 +
commit.h| 10 +++
gpg-interface.h | 11 +++
pretty.c| 91 +
4 files changed, 93
Signed-off-by: Sebastian Götte ja...@physik-pool.tu-berlin.de
---
commit.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/commit.c b/commit.c
index eb645af..3a8453d 100644
--- a/commit.c
+++ b/commit.c
@@ -1036,13 +1036,20 @@ static void
When --verify-signatures is specified on the command-line of git-merge
or git-pull, check whether the commits being merged have good gpg
signatures and abort the merge in case they do not. This allows e.g.
auto-deployment from untrusted repo hosts.
Signed-off-by: Sebastian Götte
When --verify-signatures is specified, abort the merge in case a good
GPG signature from an untrusted key is encountered.
Signed-off-by: Sebastian Götte ja...@physik-pool.tu-berlin.de
---
Documentation/merge-options.txt| 4 ++--
builtin/merge.c| 2 ++
commit.c
Expand %G? in pretty format strings to 'N' in case of no GPG signature
and 'U' in case of a good but untrusted GPG signature in addition to
the previous 'G'ood and 'B'ad. This eases writing anyting parsing
git-log output.
Signed-off-by: Sebastian Götte ja...@physik-pool.tu-berlin.de
---
Thanks for taking the time and effort to review my thoughts.
Jens Lehmann wrote:
A
commit is the thing to record here because it *is* the perfect fit
Might be, but saying that doesn't help one bit. I want to know why.
I want to improve the user experience
of submodules and don't care much
Jeff King wrote:
[...]
So, you're saying: don't test compound statements for failure, since
anything in the chain could fail and propagate failure. I should only
test simple git-foo commands for failure?
Sometimes it's annoyingly verbose to break down a compound function. But
I think in this
Junio C Hamano wrote:
Jeff King p...@peff.net writes:
[...]
Thanks. That is one of the reasons why we do not want to see too
many custom test helper functions.
I noticed that you queued my original series without modification in
rr/triangle. Should I submit a re-roll with Peff's suggestion
Junio C Hamano wrote:
sub foo ($) { my ($arg) = @_; print $arg\n; }
sub bar { my ($arg) = @_; print $arg\n; }
my @baz = (100, 101, 102);
foo @baz; # says 3
bar @baz; # says 100
Ouch. Please drop this patch; I'll resubmit when I feel confident
about my change.
This
On Mon, Apr 01, 2013 at 02:21:22AM +0530, Ramkumar Ramachandra wrote:
Jeff King wrote:
[...]
So, you're saying: don't test compound statements for failure, since
anything in the chain could fail and propagate failure. I should only
test simple git-foo commands for failure?
Right.
The function already knows when interpreting $foo^{commit} to tell
the underlying get_sha1_1() to expect a commit-ish while evaluating
$foo. Teach it to do the same when asked for $foo^{tree}; we are
expecting a tree-ish and $foo should be disambiguated in favor of a
tree-ish, discarding a
A string that names an object can be suffixed with ^{type} peeler to
say I have this object name; peel it until you get this type. If
you cannot do so, it is an error. v1.8.2^{commit} asks for a commit
that is pointed at an annotated tag v1.8.2; v1.8.2^{tree} unwraps it
further to the top-level
Michael Haggerty mhag...@alum.mit.edu writes:
... Though honestly, I don't see the point of using
--default as opposed to
$ git rev-parse --verify ${REV:-master}^{commit}
I would agree ${VAR:-default} is sufficient in that particular case.
The --default is more about the use of the
Ramkumar Ramachandra wrote:
Jens Lehmann wrote:
A
commit is the thing to record here because it *is* the perfect fit
Might be, but saying that doesn't help one bit. I want to know why.
[...]
To summarize, everyone seems to be elated with the current state of
submodules and is vehemently
On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Thanks for taking the time and effort to review my thoughts.
Jens Lehmann wrote:
A
commit is the thing to record here because it *is* the perfect fit
Might be, but saying that doesn't help one bit. I want to
In message
CALkWK0=csuawqwk5guf0pbc4_zeoziwqpamcrvbgz5lj0qg...@mail.gmail.com, Ramkumar
Ramachandra writes:
As a user inexperienced with recursive submodules (I've only used them
in this repository), I found it highly confusing. Thanks for clearing
them up.
You may want to
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
sub foo ($) { my ($arg) = @_; print $arg\n; }
sub bar { my ($arg) = @_; print $arg\n; }
my @baz = (100, 101, 102);
foo @baz; # says 3
bar @baz; # says 100
Ouch. Please drop this patch; I'll
From: Ramkumar Ramachandra artag...@gmail.com
All the callers of ask, extract_valid_address, and validate_patch
subroutines assign the return values from them to a single scaler:
$var = subr(...);
and return undef; in these subroutine can safely be turned into a
simpler return;. Doing
From: Ramkumar Ramachandra artag...@gmail.com
The subroutine check_file_rev_conflict() is called from two places,
both of which expects to pass a single scaler variable and see if
that can be interpreted as a pathname or a revision name. It is
defined with a function prototype ($) to force a
From: Ramkumar Ramachandra artag...@gmail.com
Perlcritic does not want to see the trailing pipe in the two-args
form of open(), i.e.
open my $fh, $cmd \Q$file\E |;
If $cmd were a single-token command name, it would make a lot more
sense to use four-or-more-args form open
Jeff King p...@peff.net writes:
On Mon, Apr 01, 2013 at 02:21:22AM +0530, Ramkumar Ramachandra wrote:
Jeff King wrote:
[...]
So, you're saying: don't test compound statements for failure, since
anything in the chain could fail and propagate failure. I should only
test simple git-foo
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
Jeff King p...@peff.net writes:
[...]
Thanks. That is one of the reasons why we do not want to see too
many custom test helper functions.
I noticed that you queued my original series without modification in
Junio C Hamano wrote:
From: Ramkumar Ramachandra artag...@gmail.com
The subroutine check_file_rev_conflict() is called from two places,
both of which expects to pass a single scaler variable and see if
that can be interpreted as a pathname or a revision name. It is
defined with a function
Junio C Hamano wrote:
we cannot rewrite it to
open my $fh, -|, $cmd, $file;
for extra safety. At least, by using this in the three-arg form:
open my $fh, -|, $cmd \Q$file\E;
we can silence Perlcritique, even though we do not gain much safety
by doing so.
Sebastian Götte ja...@physik.tu-berlin.de writes:
+ if (verify_signatures) {
+ for (p = remoteheads; p; p = p-next) {
+ struct commit *commit = p-item;
+ char hex[41];
+ struct signature_check signature_check;
+
John Keeping j...@keeping.me.uk writes:
A formatting fix for a patch currently cooking on nd/magic-pathspecs
(cc3d8045ec1e2323c5654e2af834e887f26deb7e).
---
The latest version of this wasn't posted to the list in full, so I'm not
sure about the recommended way to provide feedback.
Robin Rosenberg robin.rosenb...@dewire.com writes:
Signed-off-by: Robin Rosenberg robin.rosenb...@dewire.com
---
contrib/completion/git-prompt.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/contrib/completion/git-prompt.sh
b/contrib/completion/git-prompt.sh
index
Jonathon Mah m...@jonathonmah.com writes:
Signed-off-by: Jonathon Mah m...@jonathonmah.com
---
The previous message was incorrect when not enough arguments were
specified:
$ git branch -m
fatal: too many branches for a rename operation
I changed to branch name required
Junio C Hamano gits...@pobox.com writes:
Jonathon Mah m...@jonathonmah.com writes:
Signed-off-by: Jonathon Mah m...@jonathonmah.com
---
The previous message was incorrect when not enough arguments were
specified:
$ git branch -m
fatal: too many branches for a rename
On Mon, Apr 1, 2013 at 9:51 AM, Junio C Hamano gits...@pobox.com wrote:
John Keeping j...@keeping.me.uk writes:
A formatting fix for a patch currently cooking on nd/magic-pathspecs
(cc3d8045ec1e2323c5654e2af834e887f26deb7e).
---
The latest version of this wasn't posted to the list in full,
Junio C Hamano gits...@pobox.com writes:
The only reason a topic is queued in 'pu' is to let me not pay
attention to it, without risking to forget about it completely ;-).
The topics on 'pu' have potential to be a useful change even though
they are far from ready for 'next'.
That's not even
On Sun, Mar 31, 2013 at 9:40 PM, Junio C Hamano gits...@pobox.com wrote:
All the callers of ask, extract_valid_address, and validate_patch
subroutines assign the return values from them to a single scaler:
s/scaler/scalar/g
(note the /g)
$var = subr(...);
and return undef; in
On Sun, Mar 31, 2013 at 9:40 PM, Junio C Hamano gits...@pobox.com wrote:
The subroutine check_file_rev_conflict() is called from two places,
both of which expects to pass a single scaler variable and see if
s/scaler/scalar/g
(note the /g)
that can be interpreted as a pathname or a revision
Hi,
Nguyễn Thái Ngọc Duy wrote:
git checkout -- paths is usually used to restore all modified
files in paths. In sparse checkout mode, this command is overloaded
with another meaning: to add back all files in paths that are
excluded by sparse patterns.
Add --no-widen option to do what
Junio C Hamano gits...@pobox.com writes:
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
Jeff King p...@peff.net writes:
[...]
Thanks. That is one of the reasons why we do not want to see too
many custom test helper functions.
I noticed that you queued my original
Jonathan Nieder jrnie...@gmail.com writes:
Nguyễn Thái Ngọc Duy wrote:
git checkout -- paths is usually used to restore all modified
files in paths. In sparse checkout mode, this command is overloaded
with another meaning: to add back all files in paths that are
excluded by sparse patterns.
On Mon, Apr 1, 2013 at 11:48 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Hi,
Nguyễn Thái Ngọc Duy wrote:
git checkout -- paths is usually used to restore all modified
files in paths. In sparse checkout mode, this command is overloaded
with another meaning: to add back all files in paths
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
Jeff King p...@peff.net writes:
[...]
Thanks. That is one of the reasons why we do not want to see too
many custom test helper
70 matches
Mail list logo