On 6/6/2019 3:05 PM, Jeff King wrote:
> On Thu, Jun 06, 2019 at 03:00:00PM -0400, Eric Sunshine wrote:
>
>>> I can't reproduce the intermittent failure either on 2.21.0, or with
>>> v2.22.0-rc3.
>>
>> I can't reproduce it either on Jeff's Solaris box. Perhaps Jeff can
>> add "-v -x" to his automat
On Thu, Jun 06, 2019 at 03:00:00PM -0400, Eric Sunshine wrote:
> > I can't reproduce the intermittent failure either on 2.21.0, or with
> > v2.22.0-rc3.
>
> I can't reproduce it either on Jeff's Solaris box. Perhaps Jeff can
> add "-v -x" to his automated build/test script in order to help
> diag
On Thu, Jun 6, 2019 at 1:35 PM Jeff King wrote:
> On Thu, Jun 06, 2019 at 01:18:01PM -0400, Eric Sunshine wrote:
> > > > not ok 12 - check normal git operations: twelve packs
> >
> > Jeff Walton reported this to me privately. I'm not familiar with this
> > code and don't have time presently to inv
On Thu, Jun 06, 2019 at 01:18:01PM -0400, Eric Sunshine wrote:
> > > not ok 12 - check normal git operations: twelve packs
> > > #
> > > # midx_git_two_modes "rev-list --objects --all" &&
> > > # midx_git_two_modes "log --raw" &&
> > > #
[forwarding to the Git list]
On Sun, Jun 2, 2019 at 6:23 AM Jeffrey Walton wrote:
> On Sun, Jun 2, 2019 at 5:09 AM Jeffrey Walton wrote:
> > I'm catching a self test failure on Solaris 11.3. Git 2.21 from sources.
> >
> > ok 8 - check normal git operations: two packs
On Wed, Aug 1, 2018 at 1:39 AM Jonathan Nieder wrote:
> SZEDER Gábor wrote:
>
> > While 3secs timeout seems plenty, and indeed is sufficient in most
> > cases, on rare occasions it's just not quite enough: I saw this test
> > fail in Travis CI build jobs two, maybe three times because 'git
> > upd
Hi,
SZEDER Gábor wrote:
> While 3secs timeout seems plenty, and indeed is sufficient in most
> cases, on rare occasions it's just not quite enough: I saw this test
> fail in Travis CI build jobs two, maybe three times because 'git
> update-ref' timed out.
I suspect these tests will fail with val
The test 'no bogus intermediate values during delete' in
't1404-update-ref-errors.sh', added in 6a2a7736d8 (t1404: demonstrate
two problems with reference transactions, 2017-09-08), tries to catch
undesirable side effects of deleting a ref, both loose and packed, in
a transaction. To do so it is h
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t7900-subtree.sh | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/t/t7900-subtree.sh b/t/t7900-subtree.sh
index eb223ff049..a6e7103f92 100755
--- a/t/t7900-subtree.sh
+++ b/t/t7900-subtree.sh
@@ -38,6 +38,16 @@ check_equ
On 04/01/18 20:55, Johannes Schindelin wrote:
> On Tue, 2 Jan 2018, Ramsay Jones wrote:
[snip]
>> Also, when logged-in remotely it fails consistently, when logged-in
>> directly it passes consistently. :-D
>
> You are most likely hitting cmd.exe at some point there. In cmd.exe, there
> are some
Hi,
On Tue, 2 Jan 2018, Ramsay Jones wrote:
> On 02/01/18 15:32, Ramsay Jones wrote:
> > On 02/01/18 11:36, Adam Dinwoodie wrote:
> >> On Saturday 30 December 2017 at 02:40 pm +, Adam Dinwoodie wrote:
> >>> On Saturday 30 December 2017 at 02:21 pm +, Ramsay Jones wrote:
> [snip]
> >> I'm
On 02/01/18 15:32, Ramsay Jones wrote:
> On 02/01/18 11:36, Adam Dinwoodie wrote:
>> On Saturday 30 December 2017 at 02:40 pm +, Adam Dinwoodie wrote:
>>> On Saturday 30 December 2017 at 02:21 pm +, Ramsay Jones wrote:
[snip]
>> I'm not able to reproduce this: t5580 is passing on both my
On 02/01/18 11:36, Adam Dinwoodie wrote:
> On Saturday 30 December 2017 at 02:40 pm +, Adam Dinwoodie wrote:
>> On Saturday 30 December 2017 at 02:21 pm +, Ramsay Jones wrote:
>>> Hi Junio, Adam,
>>>
>>> Just a quick note about the failure of the test-suite on cygwin.
>>> In particular, t
On Saturday 30 December 2017 at 02:40 pm +, Adam Dinwoodie wrote:
> On Saturday 30 December 2017 at 02:21 pm +, Ramsay Jones wrote:
> > Hi Junio, Adam,
> >
> > Just a quick note about the failure of the test-suite on cygwin.
> > In particular, test t5580-clone-push-unc.sh #3, like so:
> >
On Saturday 30 December 2017 at 02:21 pm +, Ramsay Jones wrote:
> Hi Junio, Adam,
>
> Just a quick note about the failure of the test-suite on cygwin.
> In particular, test t5580-clone-push-unc.sh #3, like so:
>
>
>
> Adam, are you running the tests on Windows 10?
I'm only routinely testing
Hi Junio, Adam,
Just a quick note about the failure of the test-suite on cygwin.
In particular, test t5580-clone-push-unc.sh #3, like so:
$ ./t5580-clone-push-unc.sh -i -v
...
ok 2 - clone
expecting success:
(
cd clone &&
git checkout -b to-pu
On Thu, Oct 12, 2017 at 01:27:57AM +0100, Ramsay Jones wrote:
> On 11/10/17 23:34, Adam Dinwoodie wrote:
> [snip]
> > Hi Ramsay,
> >
> > I assume, given you're emailing me, that this is a Cygwin failure?
>
> Yes, sorry, I should have made that clear.
>
> > t0021.15 has PERL as a requirement, and
On 11/10/17 23:34, Adam Dinwoodie wrote:
[snip]
> Hi Ramsay,
>
> I assume, given you're emailing me, that this is a Cygwin failure?
Yes, sorry, I should have made that clear.
> t0021.15 has PERL as a requirement, and I see semi-regular failures from
> Git tests that are Perl-based in one way o
Hi,
Adam Dinwoodie wrote:
> t0021.15 has PERL as a requirement, and I see semi-regular failures from
> Git tests that are Perl-based in one way or another (git-svn tests are
> the most common problems). I've not spotted t0021 failing in that way,
> but it sounds like the same class of problem.
>
On Wed, Oct 11, 2017 at 11:15:57PM +0100, Ramsay Jones wrote:
> Hi Adam,
>
> I had a test failure on the v2.15.0-rc1 build tonight.
> The test in question being t0021-conversion.sh #15
> ('required process filter should filter data'). I didn't
> have any test fai
On 11/10/17 23:15, Ramsay Jones wrote:
> Hi Adam,
>
> I had a test failure on the v2.15.0-rc1 build tonight.
> The test in question being t0021-conversion.sh #15
> ('required process filter should filter data'). I didn't
> have any test failures on v2.15.0-rc0,
Hi Adam,
I had a test failure on the v2.15.0-rc1 build tonight.
The test in question being t0021-conversion.sh #15
('required process filter should filter data'). I didn't
have any test failures on v2.15.0-rc0, and I don't see
any change that would have affected this test.
A
Johannes Sixt writes:
> I observe the test failure below in t0040-parse-options.sh. It bisects
> to 1a7909b25eb4ab3071ce4290115618e2582eadaa "Convert pack-objects to
> size_t". It looks like git_parse_size_t() needs a fix. This is on
> Windows, 32 bit. size_t, int and lon
I observe the test failure below in t0040-parse-options.sh. It bisects
to 1a7909b25eb4ab3071ce4290115618e2582eadaa "Convert pack-objects to
size_t". It looks like git_parse_size_t() needs a fix. This is on
Windows, 32 bit. size_t, int and long are all 32 bits wide.
expecti
Thanks for a quick report. Yes, that was a stupid mismerge.
Will correct in my rerere database X-<.
Hi Junio,
t6134 fails for me in 'pu', but I think it is just a question
of merge 641f3ad90a3 dropping the last line of the test from
the change introduced by commit bdab972153.
In other words, this fixes the test for me:
$ git diff
diff --git a/t/t6134-pathspec-in-submodule.sh b/t/t6134-pathspec
> On 17 Dec 2016, at 15:28, Lars Schneider wrote:
>
>
>> On 16 Dec 2016, at 21:32, Ramsay Jones wrote:
>>
>> Hi Lars,
>>
>> For the last two days, I've noticed t0021.15 on the 'pu' branch has been
>> failing intermittently (well it fails with: 'make test >ptest-out', but
>> when run by hand
> On 16 Dec 2016, at 21:32, Ramsay Jones wrote:
>
> Hi Lars,
>
> For the last two days, I've noticed t0021.15 on the 'pu' branch has been
> failing intermittently (well it fails with: 'make test >ptest-out', but
> when run by hand, it fails only say 1-in-6, 1-in-18, etc.).
>
> [yes, it's a bi
Hi Lars,
For the last two days, I've noticed t0021.15 on the 'pu' branch has been
failing intermittently (well it fails with: 'make test >ptest-out', but
when run by hand, it fails only say 1-in-6, 1-in-18, etc.).
[yes, it's a bit strange; this hasn't changed in a couple of weeks!]
I don't have
> On Oct 10, 2016, at 09:44, Junio C Hamano wrote:
>
> Jeremy Huddleston Sequoia writes:
>
>> Regressed-in: 610d55af0f082f6b866dc858e144c03d8ed4424c
>> Signed-off-by: Jeremy Huddleston Sequoia
>> CC: Thomas Gummerer
>> CC: Junio C Hamano
>
> This is also under-explained. Was the test brok
Jeremy Huddleston Sequoia writes:
> Regressed-in: 610d55af0f082f6b866dc858e144c03d8ed4424c
> Signed-off-by: Jeremy Huddleston Sequoia
> CC: Thomas Gummerer
> CC: Junio C Hamano
This is also under-explained. Was the test broken for everybody and
you are the first to report, or was your enviro
Regressed-in: 610d55af0f082f6b866dc858e144c03d8ed4424c
Signed-off-by: Jeremy Huddleston Sequoia
CC: Thomas Gummerer
CC: Junio C Hamano
---
t/t3700-add.sh | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index 924a266..3ccb19b 100755
On Wed, Jun 22, 2016 at 06:53:40PM +0200, Armin Kunaschik wrote:
> Another thread I'm trying to revive... the discussion went away quite a bit
> from the suggested patch to conditionally run this one test only when mktemp
> is available.
>
> I'll create a patch when there are chances it is accept
Another thread I'm trying to revive... the discussion went away quite a bit
from the suggested patch to conditionally run this one test only when mktemp
is available.
I'll create a patch when there are chances it is accepted.
I could think of a way to replace mktemp with a perl one-liner (or
smal
On Fri, May 27, 2016 at 12:58:15PM -0700, Junio C Hamano wrote:
> On Fri, May 27, 2016 at 11:24 AM, Jeff King wrote:
> > Which perhaps shows that maybe some people would
> > see a performance regression if we moved from /tmp to a slower
> > filesystem (e.g., especially people whose git clone is o
On Fri, May 27, 2016 at 11:24 AM, Jeff King wrote:
> Which perhaps shows that maybe some people would
> see a performance regression if we moved from /tmp to a slower
> filesystem (e.g., especially people whose git clone is on NFS or
> something).
Yup, but they would be using "--root" already if
On Thu, May 26, 2016 at 11:33:27PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > The only one I can think of is that if something leaves cruft in
> > $TMPDIR, it could affect later tests that want to `git add`
> > indiscriminately.
>
> Or "git ls-files -u", "git clean", etc. I'd mostl
David Aguilar writes:
> Another alternative is that we can compile our own
> "git-readlink" and "git-mktemp" programs and use those instead,
> but that seems like a big maintenance burden compared to the
> relative simplicity of the test-suite workarounds.
Not _that_ big burden as we already hav
Jeff King writes:
> The only one I can think of is that if something leaves cruft in
> $TMPDIR, it could affect later tests that want to `git add`
> indiscriminately.
Or "git ls-files -u", "git clean", etc. I'd mostly worry about a
failed test in which a program dies without a chance to clean u
On Thu, May 26, 2016 at 09:40:27PM -0700, David Aguilar wrote:
> > BTW, one thing I happened to note while looking at this: running the
> > test script will write into /tmp (or wherever your $TMPDIR points).
> > Probably not a big deal, but I wonder if we should be setting $TMPDIR in
> > our test
On Wed, May 25, 2016 at 08:51:14PM -0500, Jeff King wrote:
> On Wed, May 25, 2016 at 06:16:15PM -0500, Jeff King wrote:
>
> > On Tue, May 24, 2016 at 09:45:25AM -0700, Junio C Hamano wrote:
> >
> > > On Tue, May 24, 2016 at 9:44 AM, Armin Kunaschik
> > > wrote:
> > > > t7610-mergetool.sh fails o
On Wed, May 25, 2016 at 11:33:33AM +0200, Armin Kunaschik wrote:
> On Tue, May 24, 2016 at 7:36 PM, Junio C Hamano wrote:
> > Armin Kunaschik writes:
> >>
> >> Ok, how can this be implemented within the test environment?
> >
> > I actually think an unconditional check like this is sufficient.
>
On Wed, May 25, 2016 at 06:16:15PM -0500, Jeff King wrote:
> On Tue, May 24, 2016 at 09:45:25AM -0700, Junio C Hamano wrote:
>
> > On Tue, May 24, 2016 at 9:44 AM, Armin Kunaschik
> > wrote:
> > > t7610-mergetool.sh fails on systems without mktemp.
> > >
> > > mktemp is used in git-mergetool.sh
On Tue, May 24, 2016 at 09:45:25AM -0700, Junio C Hamano wrote:
> On Tue, May 24, 2016 at 9:44 AM, Armin Kunaschik
> wrote:
> > t7610-mergetool.sh fails on systems without mktemp.
> >
> > mktemp is used in git-mergetool.sh and throws an error when it's not
> > available.
> > error: mktemp is nee
On Tue, May 24, 2016 at 7:36 PM, Junio C Hamano wrote:
> Armin Kunaschik writes:
>>
>> Ok, how can this be implemented within the test environment?
>
> I actually think an unconditional check like this is sufficient.
Ah, good. My thoughts were a bit more complicated.
Anyway, this works for me.
T
Armin Kunaschik writes:
>> I wouldn't allow it in our scripted Porcelain, but the environment
>> of our test scripts are under our control, so I do not think it is a
>> problem ("ls piped to sed" has been an established idiom before
>> readlink(1) was widely accepted, by the way).
>
> I think so
On Tue, May 24, 2016 at 6:57 PM, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> Armin Kunaschik writes:
>>
>>> t7800 fails on systems where readlink (GNUism?) is not available.
>>
>> I don't think it's POSIX, but it is present on all POSIX-like systems I
>> know. On which system did you get t
Matthieu Moy writes:
> Armin Kunaschik writes:
>
>> t7800 fails on systems where readlink (GNUism?) is not available.
>
> I don't think it's POSIX, but it is present on all POSIX-like systems I
> know. On which system did you get the issue?
>
>> +readlink() { ls -ld "$1" | sed 's/.* -> //'; }
>
On Tue, May 24, 2016 at 6:45 PM, Junio C Hamano wrote:
> 3. find and install mktemp?
Sure, but which one? :-) mktemp is not mentioned in POSIX.
http://stackoverflow.com/questions/2792675/how-portable-is-mktemp1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a mes
Armin Kunaschik writes:
> t7800 fails on systems where readlink (GNUism?) is not available.
I don't think it's POSIX, but it is present on all POSIX-like systems I
know. On which system did you get the issue?
> +readlink() { ls -ld "$1" | sed 's/.* -> //'; }
This is much less robust than the a
On Tue, May 24, 2016 at 9:44 AM, Armin Kunaschik
wrote:
> t7610-mergetool.sh fails on systems without mktemp.
>
> mktemp is used in git-mergetool.sh and throws an error when it's not
> available.
> error: mktemp is needed when 'mergetool.writeToTemp' is true
>
> I see 2 options:
> 1. code around
t7610-mergetool.sh fails on systems without mktemp.
mktemp is used in git-mergetool.sh and throws an error when it's not available.
error: mktemp is needed when 'mergetool.writeToTemp' is true
I see 2 options:
1. code around it, write an own mktemp, maybe use the test-mktemp as a basis.
2. disabl
t7800 fails on systems where readlink (GNUism?) is not available.
An easy workaround for the very basic readlink usage of this test
would be to use a shell function like this:
---
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index ff7a9e9..be3d19f 100755
--- a/t/t7800-difftool.sh
+++ b/t
On 21/10/15 18:50, David Turner wrote:
> On Wed, 2015-10-21 at 18:05 +0200, Torsten Bögershausen wrote:
>> On 21.10.15 16:37, Ramsay Jones wrote:
>>> Hi Junio,
>>>
>>> While testing the next branch today, I had a test failure, viz:
>>>
>>>
On Wed, 2015-10-21 at 18:05 +0200, Torsten Bögershausen wrote:
> On 21.10.15 16:37, Ramsay Jones wrote:
> > Hi Junio,
> >
> > While testing the next branch today, I had a test failure, viz:
> >
> > $ tail ntest-out-fail
> > Test Summary Report
&g
On 21/10/15 17:05, Torsten Bögershausen wrote:
> On 21.10.15 16:37, Ramsay Jones wrote:
>> Hi Junio,
>>
>> While testing the next branch today, I had a test failure, viz:
>>
>> $ tail ntest-out-fail
>> Test Summary Report
>> -
On 21.10.15 16:37, Ramsay Jones wrote:
> Hi Junio,
>
> While testing the next branch today, I had a test failure, viz:
>
> $ tail ntest-out-fail
> Test Summary Report
> ---
> t7063-status-untracked-cache.sh (Wstat: 256
Hi Junio,
While testing the next branch today, I had a test failure, viz:
$ tail ntest-out-fail
Test Summary Report
---
t7063-status-untracked-cache.sh (Wstat: 256 Tests: 32
Failed: 22)
Failed tests: 1-18, 20-21, 25, 29
Non-zero exit
On 2014-11-12 22.57, Michael Blume wrote:
[t5705-clone-2gb.sh broken on Mac OS]
It is most probably even broken on every platform,
since we renovated the URL parser in 2013.
(More info can be found here:)
git log t/t5601-clone.sh
I missed t5705-clone-2gb.sh,
because it has its own enabler vari
Confirmed exists on master
On Wed, Nov 12, 2014 at 1:57 PM, Michael Blume wrote:
> This is in pu, haven't checked if it's also in master, this is the
> first time I've run this test
>
> $ GIT_TEST_CLONE_2GB=t ./t5705-clone-2gb.sh -v
> Initialized empty Git repository in
> /Users/michael.blume/wor
This is in pu, haven't checked if it's also in master, this is the
first time I've run this test
$ GIT_TEST_CLONE_2GB=t ./t5705-clone-2gb.sh -v
Initialized empty Git repository in
/Users/michael.blume/workspace/git/t/trash
directory.t5705-clone-2gb/.git/
expecting success:
git config pack.compres
On Tue, Nov 11, 2014 at 3:41 AM, Jeff King wrote:
> On Tue, Nov 11, 2014 at 02:40:19AM +0100, Johan Herland wrote:
>> > This and all other failures are due to the output of 'wc -l', which on
>> > Mac is "{whitespace}1" rather than just "1" as it is on other
>> > platforms. fbe4f748 added quotes ar
Johan Herland writes:
> Ah, thanks!
>
> I thought that quoting command output was a good idea in general. Am I
> wrong, or is this just one exception to an otherwise good guideline?
It is not a good practice to blindly follow any guideline ;-).
When you anticipate that different platforms throw
On Tue, Nov 11, 2014 at 02:40:19AM +0100, Johan Herland wrote:
> > This and all other failures are due to the output of 'wc -l', which on
> > Mac is "{whitespace}1" rather than just "1" as it is on other
> > platforms. fbe4f748 added quotes around the $(... | wc -l) invocation
> > which caused the
If quoting is generally preferred as a best practice, we could force
wc to behave more consistently before we start testing
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 0d93e33..57ed608 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -515,6 +515,14 @@
On Tue, Nov 11, 2014 at 2:19 AM, Eric Sunshine wrote:
> On Mon, Nov 10, 2014 at 7:17 PM, Michael Blume wrote:
>> the commit modernizing test 3301
>> (https://github.com/git/git/commit/fbe4f74865acfd) appears to break it
>> on my mac
>>
>> $ ./t3301-notes.sh -v
>> expecting success:
>> MSG=b4 git
On Mon, Nov 10, 2014 at 7:17 PM, Michael Blume wrote:
> the commit modernizing test 3301
> (https://github.com/git/git/commit/fbe4f74865acfd) appears to break it
> on my mac
>
> $ ./t3301-notes.sh -v
> expecting success:
> MSG=b4 git notes add &&
> test_path_is_missing .git/NOTES_EDITMSG &&
> test
my first thought was that this might be a bash versioning issue, since
the commit in question basically refactors the script, and macs ship
with an archaic version of bash, but I have the same problem with bash
4.3.30
On Mon, Nov 10, 2014 at 4:23 PM, Michael Blume wrote:
> (to be clear: I ran git
(to be clear: I ran git bisect, and traced the problem to the modernize commit)
On Mon, Nov 10, 2014 at 4:17 PM, Michael Blume wrote:
> the commit modernizing test 3301
> (https://github.com/git/git/commit/fbe4f74865acfd) appears to break it
> on my mac
>
> Verbose output follows:
>
> $ ./t3301-n
the commit modernizing test 3301
(https://github.com/git/git/commit/fbe4f74865acfd) appears to break it
on my mac
Verbose output follows:
$ ./t3301-notes.sh -v
Initialized empty Git repository in
/Users/michael.blume/workspace/git/t/trash directory.t3301-notes/.git/
expecting success:
test_must_f
$ ./t1410-reflog.sh -v -i
Initialized empty Git repository in
/Users/michael.blume/workspace/git/t/trash
directory.t1410-reflog/.git/
expecting success:
mkdir -p A/B &&
echo rat >C &&
echo ox >A/D &&
echo tiger >A/B/E &&
git add . &&
test_tick && git commit -m rabbit &&
H=`git rev-parse --verify H
On Sat, Nov 08, 2014 at 11:28:32AM -0800, Michael Blume wrote:
> When I build and run tests I get
>
> [11:17][michael.blume@tcc-michael-4:~/workspace/git/t(master)]$
> ./t1410-reflog.sh
What does "./t1410-reflog.sh -v -i" report?
> A quick search seems to indicate the test is pretty new?
> http
I'm on a macbook running a beta of Mac OS Yosemite 10.10.1. I've never
been able to get GETTEXT to work so I have
NO_GETTEXT=1
in my makefile, but other than that I'm using the master branch of the
official github mirror.
When I build and run tests I get
[11:17][michael.blume@tcc-michael-4:~/wo
Hi Junio,
The current 'pu' branch has a test failure for me, namely test
t2017-checkout-orphan.sh #9.
I had a quick squint at the conflict resolution in commit acdbdf99 and
the only thing that seemed relevant was the dropping of the
'log_all_ref_updates' dance. So, I quickly
Christoph Bonitz writes:
> Apart from your change and the word wrap adjustments suggested by
> Pete, would the following also make sense, to fix the other flaw
> Johannes pointed out? With regards to failing, git diff-tree should be
> idempotent. I think those are the two occurrences in this file
On Fri, Jul 25, 2014 at 12:05 AM, Junio C Hamano wrote:
> Johannes Sixt writes:
>> I see a few other no-nos in the context of the changes, in particular,
>> pipelines where git is not the last command; these would not catch
>> failures in the git commands. But a fix for that is certainly outside
On Thu, Jul 24, 2014 at 8:45 PM, Johannes Sixt wrote:
> Am 23.07.2014 23:28, schrieb Christoph Bonitz:
>> - test "$src" = file10 || test "$src" = file11 &&
>> + test "$src" = file2 || test "$src" = file10 || test "$src" = file11 &&
>
> You can't test for alternatives in this way. It's already wron
Johannes Sixt writes:
>> @@ -177,7 +175,7 @@ test_expect_success 'detect copies' '
>> level=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f1 |
>> cut -d" " -f5 | sed "s/C0*//") &&
>> test -n "$level" && test "$level" -gt 0 && test "$level" -lt 98 &&
>> src=$(git diff-tree
Am 23.07.2014 23:28, schrieb Christoph Bonitz:
> The scenario in the rename test makes unnecessary assumptions about
> which file git file-tree will detect as a source for a copy-operations.
> Furthermore, copy detection is not tested by checking the resulting
> perforce revision history via p4 fil
ml.christophbon...@gmail.com wrote on Wed, 23 Jul 2014 23:28 +0200:
> The scenario in the rename test makes unnecessary assumptions about
> which file git file-tree will detect as a source for a copy-operations.
> Furthermore, copy detection is not tested by checking the resulting
> perforce revisi
ot;) &&
test -n "$level" && test "$level" -gt 2 && test "$level" -lt 100 &&
- src=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f2) &&
- test "$src" = file10 || test "$src" = file11 || test &q
On Mon, Jul 7, 2014 at 11:14 PM, Junio C Hamano wrote:
> "Choosing any of these as the copy source is fine" is a sensible way
> to fix the problem with this test. Would it be a better solution to
> avoid having multiple/ambiguous copy source candidates in the first
> place, by the way?
I agree
Pete Wyckoff writes:
> I'm not sure how to robustify this. At least doing the multiple
> comparisons should make the tests work again. The goal of this
> series of tests is to make sure that copy detection is working,
> not to verify that the correct copy choice was made. That should
> be in o
ml.christophbon...@gmail.com wrote on Sun, 06 Jul 2014 16:32 +0200:
> I'm trying to get the git p4 tests to pass on my machine (OS X
> Mavericks) from master before making some changes. I'm experiencing a
> test failure in "detect copies" of the rename test.
>
&g
Hi,
I'm trying to get the git p4 tests to pass on my machine (OS X
Mavericks) from master before making some changes. I'm experiencing a
test failure in "detect copies" of the rename test.
The test creates file2 with some content, creates a few copies (each
with a co
On Tue, Oct 29, 2013 at 06:12:58PM -0700, Junio C Hamano wrote:
> > I think it was just a simple mixup caused by Brian sending two fixups to
> > t5570 as series, when they are really fixups for two different topics.
> > Not worth an immediate v1.8.4.3, I think, but you may want to
> > cherry-pick
Jeff King writes:
> On Tue, Oct 29, 2013 at 01:54:31AM +0100, Simon Ruderich wrote:
>
>> I just compiled Git v1.8.4.2 on Debian Wheezy amd64 and test
>> t5570 fails (with GIT_TEST_GIT_DAEMON=1):
>> [...]
>> Bisecting leads to this commit:
>>
>> commit 68b939b2f097b6675c4aaa17869aa81b25cb
On Tue, Oct 29, 2013 at 01:54:31AM +0100, Simon Ruderich wrote:
> I just compiled Git v1.8.4.2 on Debian Wheezy amd64 and test
> t5570 fails (with GIT_TEST_GIT_DAEMON=1):
> [...]
> Bisecting leads to this commit:
>
> commit 68b939b2f097b6675c4aaa17869aa81b25cb
> Author: Jeff King
>
Hello,
I just compiled Git v1.8.4.2 on Debian Wheezy amd64 and test
t5570 fails (with GIT_TEST_GIT_DAEMON=1):
--- expect 2013-10-28 23:27:26.792409631 +
+++ output 2013-10-28 23:27:26.788409614 +
@@ -1 +1,2 @@
+Cloning into 'nowhere'...
fatal: remote error:
Hi,
I'm seeing a test failure with git-1.8.4 on powerpc-darwin8:
[11:00:56] t9903-bash-prompt.sh ...
not ok 13 - prompt - interactive rebase
not ok 14 - prompt - rebase merge
Details here:
http://paste.lisp.org/display/139525
The odd thing is that w
Ramkumar Ramachandra writes:
> Hi Junio,
>
> Junio C Hamano wrote:
>> Matthieu Moy writes:
>>
>>> Junio C Hamano writes:
>>>
I haven't been paying attention, but does that mean on that system,
a total stranger kseygold can write, modify, and remove whatever Ram
owns? I am hoping
Ramkumar Ramachandra wrote:
Hi Junio,
Junio C Hamano wrote:
Matthieu Moy writes:
Junio C Hamano writes:
I haven't been paying attention, but does that mean on that system,
a total stranger kseygold can write, modify, and remove whatever
Ram owns? I am hoping that is not the case.
I can
Hi Junio,
Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> Junio C Hamano writes:
>>
>>> I haven't been paying attention, but does that mean on that system,
>>> a total stranger kseygold can write, modify, and remove whatever Ram
>>> owns? I am hoping that is not the case.
>>
>> I can see two
Hi,
Matthieu Moy wrote:
> I can see two reasons for having the same UID for two login names:
>
> 1) the sysadmin really messed up, and as you say, a total stranger has
> complete ownership of your files. Ramkumar, you should check that this
> is not your case.
Looks like my sysadmin really screwe
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> I haven't been paying attention, but does that mean on that system,
>> a total stranger kseygold can write, modify, and remove whatever Ram
>> owns? I am hoping that is not the case.
>
> I can see two reasons for having the same UID for two log
Matthieu Moy wrote:
Junio C Hamano writes:
I haven't been paying attention, but does that mean on that system,
a total stranger kseygold can write, modify, and remove whatever Ram
owns? I am hoping that is not the case.
I can see two reasons for having the same UID for two login names:
1)
Ramkumar Ramachandra writes:
> Hi Andreas,
>
> Andreas Schwab wrote:
>> Ramkumar Ramachandra writes:
>>
>>> Hi Matthieu,
>>>
>>> Matthieu Moy wrote:
Do you have any user with this login (finger kseygold)? I suspect you
have two usernames with the same user ID.
>>>
>>> Login: kseygold
Junio C Hamano writes:
> I haven't been paying attention, but does that mean on that system,
> a total stranger kseygold can write, modify, and remove whatever Ram
> owns? I am hoping that is not the case.
I can see two reasons for having the same UID for two login names:
1) the sysadmin reall
Matthieu Moy writes:
> Ramkumar Ramachandra writes:
>
>> Hi again,
>>
>> Matthieu Moy wrote:
>>> Does this user have the same UID as your usual user
>>> (id kseygold; id $LOGNAME)?
>>
>> Yes. What do you propose we do about the test?
>
> On a GNU system, something like this should do the trick:
Ramkumar Ramachandra writes:
> Hi again,
>
> Matthieu Moy wrote:
>> Does this user have the same UID as your usual user
>> (id kseygold; id $LOGNAME)?
>
> Yes. What do you propose we do about the test?
On a GNU system, something like this should do the trick:
--- a/t/t1304-default-acl.sh
+++ b
1 - 100 of 107 matches
Mail list logo
