CALL FOR PAPERS
** Find the conference links via http://www.wseas.org
Rhodes Island, Greece, July 16-19, 2013
Scientific Sponsors: Technical University of Sofia, Bulgaria, Polytechnic
University of Bari, Italy
and University Politehnica of Bucharest, Romania
17th CSCC Multic
Duy Nguyen wrote:
> On Mon, Apr 1, 2013 at 11:48 AM, Jonathan Nieder wrote:
>> I'm afraid I can't imagine when --no-respect-skip-worktree would be
>> useful. That can easily be a failure of my imagination, though.
>
> There may be scripts that expect "git checkout -- foo" to reset
> everything i
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Ramkumar Ramachandra writes:
>>
>>> Junio C Hamano wrote:
Jeff King 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
On Mon, Apr 1, 2013 at 11:48 AM, Jonathan Nieder wrote:
> Hi,
>
> Nguyễn Thái Ngọc Duy wrote:
>
>> "git checkout -- " is usually used to restore all modified
>> files in . In sparse checkout mode, this command is overloaded
>> with another meaning: to add back all files in that are
>> excluded by
Jonathan Nieder writes:
> Nguyễn Thái Ngọc Duy wrote:
>
>> "git checkout -- " is usually used to restore all modified
>> files in . In sparse checkout mode, this command is overloaded
>> with another meaning: to add back all files in that are
>> excluded by sparse patterns.
>>
>> Add "--no-widen
Junio C Hamano writes:
> Ramkumar Ramachandra writes:
>
>> Junio C Hamano wrote:
>>> Jeff King 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
Hi,
Nguyễn Thái Ngọc Duy wrote:
> "git checkout -- " is usually used to restore all modified
> files in . In sparse checkout mode, this command is overloaded
> with another meaning: to add back all files in that are
> excluded by sparse patterns.
>
> Add "--no-widen" option to do what normal mod
On Sun, Mar 31, 2013 at 9:40 PM, Junio C Hamano 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 name. It is
> d
On Sun, Mar 31, 2013 at 9:40 PM, Junio C Hamano 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 these su
Junio C Hamano 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 though" but
On Mon, Apr 1, 2013 at 9:51 AM, Junio C Hamano wrote:
> John Keeping 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
Junio C Hamano writes:
> Jonathon Mah writes:
>
>> Signed-off-by: Jonathon Mah
>> ---
>>
>> 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 requ
Jonathon Mah writes:
> Signed-off-by: Jonathon Mah
> ---
>
> 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" instead of "new branch name requ
Robin Rosenberg writes:
> Signed-off-by: Robin Rosenberg
> ---
> 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 341422a..756a951 100644
> --- a/contrib/completion/git-prom
John Keeping 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. Hopefully this is
> e
Sebastian Götte writes:
> + if (verify_signatures) {
> + for (p = remoteheads; p; p = p->next) {
> + struct commit *commit = p->item;
> + char hex[41];
> + struct signature_check signature_check;
> + m
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
Junio C Hamano wrote:
> From: Ramkumar Ramachandra
>
> 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 ($)
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Jeff King 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
Jeff King 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 c
From: Ramkumar Ramachandra
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 FILEHANDLE,MODE,CMD,ARGS"
to av
From: Ramkumar Ramachandra
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 so will a
From: Ramkumar Ramachandra
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 scaler context
while e
Ramkumar Ramachandra 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 resubm
In message
, 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 investigate third party alternatives like gitslave
http://gitslave.sf.net
On Sun, Mar 31, 2013 at 4:34 PM, Ramkumar Ramachandra
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 know why.
>
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 vehe
Michael Haggerty 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 pluming command not
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
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 possibl
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.
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.
Junio C Hamano wrote:
> Jeff King 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
incorpora
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 th
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 mu
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
---
Documentation/pretty-formats.txt | 3 ++
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
---
Documentation/merge-options.txt| 4 ++--
builtin/merge.c| 2 ++
commit.c | 14 ++
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
---
Documentatio
Signed-off-by: Sebastian Götte
---
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 parse_gpg_output(struct signature_check
*sigc)
Signed-off-by: Sebastian Götte
---
commit.c| 59 +
commit.h| 10 +++
gpg-interface.h | 11 +++
pretty.c| 91 +
4 files changed, 93 insertions(+), 78 deletions(-)
diff --gi
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);
Sebastian Götte 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
On Sun, Mar 31, 2013 at 05:03:44PM +0200, Thomas Rast wrote:
> John Keeping 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 @@ st
On 03/31/2013 05:03 PM, Thomas Rast wrote:
> John Keeping 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 {
>>> } sig
John Keeping 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:] GOODSI
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
> ---
> Documentation/merge-options.txt| 4 ++--
> builtin/merge
On Sun, Mar 31, 2013 at 04:32:52PM +0200, Sebastian Götte wrote:
>
> Signed-off-by: Sebastian Götte
> ---
> 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/commi
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
---
Documentation/pretty-formats.txt | 3 ++
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
---
Documentation/merge-options.txt| 4 ++--
builtin/merge.c| 2 ++
commit.c | 13 ++
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
---
Documentatio
Signed-off-by: Sebastian Götte
---
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 result;
const char *ch
Signed-off-by: Sebastian Götte
---
commit.c| 59 +
commit.h| 10 +++
gpg-interface.h | 11 +++
pretty.c| 91 +
4 files changed, 93 insertions(+), 78 deletions(-)
diff --gi
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
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" wrote:
> >
> >> expecting success:
> >> test_must_fail git merge --ff-only --verify-signatures side-untrusted
> >> 2>mergeerror &&
> >>test_i18ngrep "has a
On 03/31/2013 02:16 PM, Thomas Rast wrote:
> "Sebastian Götte" wrote:
>
>> expecting success:
>> test_must_fail git merge --ff-only --verify-signatures side-untrusted
>> 2>mergeerror &&
>>test_i18ngrep "has a good, untrusted GPG signature" mergeerror
>>
>> ==1430== Conditional jump or mo
"Sebastian Götte" wrote:
>expecting success:
>test_must_fail git merge --ff-only --verify-signatures side-untrusted
>2>mergeerror &&
>test_i18ngrep "has a good, untrusted GPG signature" mergeerror
>
>==1430== Conditional jump or move depends on uninitialised value(s)
>==1430==at 0x4C
On 03/31/2013 01:38 PM, Thomas Rast wrote:
> "Sebastian Götte" wrote:
>
>> On 03/31/2013 10:32 AM, Thomas Rast wrote:
+ test_must_fail git merge --ff-only --verify-signatures
>> side-untrusted 2>mergeerror &&
+ test_i18ngrep "from an untrusted key" mergeerror
+'
>>>
>>> This test
"Sebastian Götte" wrote:
>On 03/31/2013 10:32 AM, Thomas Rast wrote:
>>> + test_must_fail git merge --ff-only --verify-signatures
>side-untrusted 2>mergeerror &&
>>> + test_i18ngrep "from an untrusted key" mergeerror
>>> +'
>>
>> This test gives me the following:
>>
>> ==26527== Conditional
--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 than
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
---
builtin/fetch.c | 6 --
builtin/receive-pack.c |
Signed-off-by: Nguyễn Thái Ngọc Duy
---
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 @@ static void sha1_
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
---
fetch-pack.c
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 --d
On 03/31/2013 10:32 AM, Thomas Rast wrote:
> Sebastian Götte 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'
>
> 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
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
---
Just noticed this issue when tracking down the failure in t7612. It
might still be a bit
Sebastian Götte 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' '
^
From: Thomas Rast
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 in
runtime.
While
From: Thomas Rast
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 take an optional pa
From: Thomas Rast
This was missed in 3da9365 (Tests: let --valgrind imply --verbose and
--tee, 2009-02-04).
Signed-off-by: Thomas Rast
---
t/README | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/t/README b/t/README
index e4128e5..bc7253c5 100644
--- a/t/README
+++ b/t/RE
From: Thomas Rast
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 --valgrind option
tests
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 t
72 matches
Mail list logo
