When I want to debug a failing test, I often end up doing:
cd t
./t4107-tab -v -i
cd tratab
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
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
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 such
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 don't work,
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 where I
2013/12/28 Junio C Hamano gits...@pobox.com:
Eric Wong normalper...@yhbt.net 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
+)
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
From: Junio C Hamano gits...@pobox.com
Christian Couder christian.cou...@gmail.com 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
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.
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
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 chrisc...@tuxfamily.org
---
cache.h | 6 ++
sha1_file.c | 3 +--
2 files changed, 7 insertions(+), 2
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
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:
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
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
---
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 chrisc...@tuxfamily.org
---
builtin/cat-file.c | 2 +-
cache.h| 2 +-
sha1_file.c| 6 +++---
streaming.c
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
This patch adds tests for git replace -l --format=fmt.
'short', 'medium' and 'long' are the only allowed values
for fmt.
'short' is the same as with no --format option.
Tests for 'medium' and 'long' are the most needed.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
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
Jonathan Nieder jrnie...@gmail.com 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,
FWIW, the issue is still present.
-- Forwarded message --
From: Alex Riesen raa.l...@gmail.com
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 git@vger.kernel.org
Hi,
it is also a way to
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 p...@peff.net wrote:
From: Ramsay Jones ram...@ramsay1.demon.co.uk
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
Signed-off-by: Junio C
On Fri, Dec 27, 2013 at 02:21:31PM -0800, Junio C Hamano wrote:
Konstantin Khomoutov flatw...@users.sourceforge.net 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
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
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
brl+...@mail.brlink.eu wrote:
* Sergey Sharybin sergey@gmail.com [131227 15:25]:
Security in this case is about being sure everyone gets exactly the
same
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.
However, we
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 will
-
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 inherit
Jeff King wrote:
When I want to debug a failing test, I often end up doing:
cd t
./t4107-tab -v -i
cd tratab
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,
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 t's
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 smoketest
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
33 matches
Mail list logo
