On Sat, Dec 28, 2013 at 03:56:55PM +0100, Alex Riesen wrote:
> it is also a way to create a fork bomb out of the innocent tool on platforms
> where pressing Ctrl-C does not terminate subprocesses of the foreground
> process (like, of course, Windows).
>
> To reproduce, run
>
>git -c remotes.
On Sat, Dec 28, 2013 at 12:51:04PM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > I am not _that_ bothered by the "known breakage", but AFAICT there is
> > zero benefit to keeping this redundant test.
>
> Devil's advocate: it ensures that anyone wrapping git's tests (like
> the old smoke
On Sat, Dec 28, 2013 at 02:13:13PM -0800, Jonathan Nieder wrote:
> So the idea if I am reading correctly is "Instead of relying on the
> implicit output directory chosen with chdir, which doesn't even work
> any more, set TEST_OUTPUT_DIRECTORY to decide where output for the
> sub-tests used by t00
Jeff King wrote:
> When I want to debug a failing test, I often end up doing:
>
> cd t
> ./t4107- -v -i
> cd tra
>
> The test names are long, so tab-completing on the trash directory is
> very helpful. Lately I've noticed that there are a bunch of crufty trash
> directories in my t/ director
Jonathan Nieder wrote:
> - git used to only use TEST_OUTPUT_DIRECTORY to decide where test
>results go. You'd have to use --root to set a custom location for
>trash directories.
>
> - in that old setup, t leaves around extra trash directories with
>--root, since the sub-tests in
Jeff King wrote:
> --- a/t/t-basic.sh
> +++ b/t/t-basic.sh
> @@ -50,11 +50,11 @@ run_sub_test_lib_test () {
> shift 2
> mkdir "$name" &&
> (
> - # Pretend we're a test harness. This prevents
> - # test-lib from writing the counts to a file that wi
Hi,
Jeff King wrote:
> Once upon a time, the test-lib library would create trash
> directories in the current working directory, unless we were
> explicitly told to put it elsewhere via --root. As a result,
> t created the sub-test trash directories inside its own
> trash directory.
>
> Howev
Yeah, i understand this. We can not protect self from every single
possible attack..
On Fri, Dec 27, 2013 at 10:26 PM, Bernhard R. Link
wrote:
> * Sergey Sharybin [131227 15:25]:
>> Security in this case is about being sure everyone gets exactly the
>> same repository as stored on the server, wi
Jeff King wrote:
> I am not _that_ bothered by the "known breakage", but AFAICT there is
> zero benefit to keeping this redundant test.
Devil's advocate: it ensures that anyone wrapping git's tests (like
the old smoketest infrastructure experiment) is able to handle an
expected failure.
But in p
On Fri, Dec 27, 2013 at 02:21:31PM -0800, Junio C Hamano wrote:
> Konstantin Khomoutov writes:
> >
> > The Git protocol does not implement it itself but you can channel it
> > over a TLS tunnel (via stunnel for instance). Unfortunately, this
> > means a specialized software and setup on both ends
On 28/12/13 10:00, Jeff King wrote:
> On Wed, Dec 25, 2013 at 11:08:57PM +0100, Erik Faye-Lund wrote:
>
>> On Sat, Dec 21, 2013 at 3:00 PM, Jeff King wrote:
>>> From: Ramsay Jones
>>>
>>> Signed-off-by: Ramsay Jones
>>> Signed-off-by: Junio C Hamano
>>> Signed-off-by: Jeff King
>>> ---
>>> c
FWIW, the issue is still present.
-- Forwarded message --
From: Alex Riesen
Date: Wed, Nov 17, 2010 at 6:10 PM
Subject: Runaway "git remote" if group definition contains a remote by
the same name
To: Git Mailing List
Hi,
it is also a way to create a fork bomb out of the innoce
Jonathan Nieder writes:
> Hi,
>
> Wolfgang Rohdewald wrote:
>> Am Mittwoch, 25. Dezember 2013, 22:53:29 schrieb Wolfgang Rohdewald:
>
>>> I suppose I should open a KDE bug report?
>>
>> I meant a ubuntu bug report of course.
>
> Yes, please. Feel free to cc me if doing so.
>
> In generally, I'm
And here is the test:
with git 1.8.5.2 this test don't pass because of git merge-base may
return duplicates and incorrect set of bases (not best common
ancestors)
---
t/t6010-merge-base.sh | 39 +++
1 file changed, 39 insertions(+)
diff --git a/t/t6010-merge-b
This patch adds tests for "git replace -l --format=".
'short', 'medium' and 'long' are the only allowed values
for .
'short' is the same as with no --format option.
Tests for 'medium' and 'long' are the most needed.
Signed-off-by: Christian Couder
---
t/t6050-replace.sh | 37 ++
When checking to see if some objects are of the same type
and when displaying the type of objects, git replace uses
the sha1_object_info() function.
Unfortunately this function by default respects replace
refs, so instead of the type of a replaced object, it
gives the type of the replacement objec
Signed-off-by: Christian Couder
---
Documentation/git-replace.txt | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index f373ab4..0a02f70 100644
--- a/Documentation/git-replace.txt
+++ b/Documenta
sha1_object_info_extended() should perform object replacement
if it is needed.
The simplest way to do that is to make it call
lookup_replace_object_extended().
And now its "unsigned flags" parameter is used as it is passed
to lookup_replace_object_extended().
Signed-off-by: Christian Couder
---
This parameter is not used yet, but it will be used to tell
sha1_object_info_extended() if it should perform object
replacement or not.
Signed-off-by: Christian Couder
---
builtin/cat-file.c | 2 +-
cache.h| 2 +-
sha1_file.c| 6 +++---
streaming.c| 2 +-
4 files chan
Currently, there is only one caller to lookup_replace_object()
that can benefit from passing it some flags, but we expect
that there could be more.
Signed-off-by: Christian Couder
---
cache.h | 6 ++
sha1_file.c | 3 +--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/cach
Since ecef (inline lookup_replace_object() calls,
May 15 2011) the read_replace_refs global variable is
checked twice, once in lookup_replace_object() and
once again in do_lookup_replace_object().
As do_lookup_replace_object() is called only from
lookup_replace_object(), we can remove the chec
Here is version 4 of a patch series to improve the way
sha1_object_info_extended() behaves when it is passed a
replaced object. The idea is to add a flags argument to it
in the same way as what has been done to read_sha1_file().
This patch series was inspired by a sub thread in this
discussion:
h
When --batch is passed to git cat-file, the sha1_object_info_extended()
function is used to get information about the objects passed to
git cat-file.
Unfortunately sha1_object_info_extended() doesn't take care of
object replacement properly, so it will often fail with a
message like this:
$ echo
The READ_SHA1_FILE_REPLACE flag is more related to using the
lookup_replace_object() function rather than the
read_sha1_file() function.
We also need such a flag to be used with sha1_object_info()
instead of read_sha1_file().
The name LOOKUP_REPLACE_OBJECT is therefore better for this
flag.
Sign
By default when listing replace refs, only the sha1 of the
replaced objects are shown.
In many cases, it is much nicer to be able to list all the
sha1 of the replaced objects along with the sha1 of the
replacment objects.
And in other cases it might be interesting to also show the
types of the re
From: Junio C Hamano
>
> Christian Couder writes:
>>
>> Ok, so would you prefer the following:
>>
>> - NAME_ONLY_REPLACE_FMT and "--format=name_only" instead of
>> SHORT_REPLACE_FMT and "--format=short"
>>
>> - NAME_AND_VALUE_REPLACE_FMT and "--format=name_and_value" instead of
>> MEDIUM_REPLACE
Hi there!
First of all: I'm new to mailing-lists, sorry if I'm doing it wrong.
I've found a bug in git merge-base, causing it to show not best common
ancestors and duplicates under some circumstances (example is given in
attached test case).
Problem cause is algorithm used in get_octopus_merge_bas
Sounds good. We don't really need the dump anyway.
On Sat, Dec 28, 2013 at 11:00 AM, Jeff King wrote:
> On Wed, Dec 25, 2013 at 11:08:57PM +0100, Erik Faye-Lund wrote:
>
>> On Sat, Dec 21, 2013 at 3:00 PM, Jeff King wrote:
>> > From: Ramsay Jones
>> >
>> > Signed-off-by: Ramsay Jones
>> > Sign
On Wed, Dec 25, 2013 at 11:08:57PM +0100, Erik Faye-Lund wrote:
> On Sat, Dec 21, 2013 at 3:00 PM, Jeff King wrote:
> > From: Ramsay Jones
> >
> > Signed-off-by: Ramsay Jones
> > Signed-off-by: Junio C Hamano
> > Signed-off-by: Jeff King
> > ---
> > compat/mingw.h | 1 +
> > 1 file changed,
2013/12/28 Junio C Hamano :
> Eric Wong writes:
>> git://git.bogomips.org/git-svn.git master
>>
>> for you to fetch changes up to 2394e94e831991348688831a384b088a424c7ace:
>>
>> git-svn: workaround for a bug in svn serf backend (2013-12-27 20:22:19
>> +)
>>
>>
On Thu, Dec 26, 2013 at 11:27:10AM -0800, Junio C Hamano wrote:
> > I still need consensus on the name here guys, parse_prefix.
> > remove_prefix or strip_prefix? If no other opinions i'll go with
> > strip_prefix (Jeff's comment before parse_prefix() also uses "strip")
>
> Yup, that comment is w
On Fri, Dec 27, 2013 at 08:47:54PM +0600, Sergey Sharybin wrote:
> > The web server software has nothing to do with HTTP[S] used by Git being
> > "smart", I think, it just has to be set up properly.
>
> Misunderstood git doc then which says "it has to be Apache, currently
> - other CGI servers do
Having a simulated "known breakage" test means that the test
suite will always tell us there is a bug to be fixed, even
though it is only simulated.
The right way to test this is in a sub-test, that can also
check that we provide the correct exit status and output.
Fortunately, we already have suc
Commit 517cd55 set HARNESS_ACTIVE unconditionally in
sub-tests, because that value affects the output of
"--verbose". t needs stable output from its sub-tests,
and we may or may not be running under a TAP harness.
That commit made the decision to always set the variable,
since it has another u
Once upon a time, the test-lib library would create trash
directories in the current working directory, unless we were
explicitly told to put it elsewhere via --root. As a result,
t created the sub-test trash directories inside its own
trash directory.
However, we noticed that this did not cov
When I want to debug a failing test, I often end up doing:
cd t
./t4107- -v -i
cd tra
The test names are long, so tab-completing on the trash directory is
very helpful. Lately I've noticed that there are a bunch of crufty trash
directories in my t/ directory, which makes my tab-completion m
36 matches
Mail list logo
