* Re: master has some toys
From: Junio C Hamano @ 2005-11-18 4:27 UTC (permalink / raw)
To: John Benes; +Cc: git
In-Reply-To: <437D5219.6060300@gmail.com>
John Benes <smartcat99s@gmail.com> writes:
> diff --git a/file4 b/file4
> index
> edc575dec543a684da5007b43886ee32ecb381ae..adb07b7ad3fa2c63251b06d1d39cb90a
> 85b860b4 100644
> Files a/file4 and b/file4 differ
Thanks. This is the same problem as what Large Angly SCM
reports. What does your "diff --version" say?
^ permalink raw reply
* Re: master has some toys
From: Junio C Hamano @ 2005-11-18 4:26 UTC (permalink / raw)
To: git
In-Reply-To: <437D4F57.9070303@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> Files /dev/null and b/file3 differ
> diff --git a/file4 b/file4
> index
> edc575dec543a684da5007b43886ee32ecb381ae..adb07b7ad3fa2c63251b06d1d39cb90a85b860b4
> 100644
> Files a/file4 and b/file4 differ
Thanks. I've seen enough. I expected diff (GNU diffutils 2.8.1
is what I have handy) output which says "Binary files a/foo and
b/foo differ".
Hmph. Now I'd need to find a way to catch at least these two
cases...
^ permalink raw reply
* Re: master has some toys
From: John Benes @ 2005-11-18 4:01 UTC (permalink / raw)
To: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.63.0511180345450.6359@wbgn013.biozentrum.uni-wuerzburg.de>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Johannes Schindelin wrote:
> BTW, it would be more helpful if you do not just tell *what* test fails,
> but *how*. For example, try to run "git-whatchanged -p" and send just
> the first page of the output (both stdout and stderr). I bet it says it
> has a problem fixing up mmap() after fork().
I ran "git-whatchanged -p" with the previously mentioned master build
installed in /usr/bin. Below is a copy of the command session.
Stdout was redirected to test2.txt, which is located at:
http://www.penguinlounge.1and2.org/videos/test2.txt.bz2
Twinkie@squirrel ~/git
$ git-whatchanged -p > ../test2.txt
Twinkie@squirrel ~/git
$ cd ..
Twinkie@squirrel ~
$ ls -la test2.txt
- -rw-r--r-- 1 Twinkie None 9338905 Nov 17 21:23 test2.txt
nothing was displayed on stderr.
The make test error was shown on linux too. [1]
It reports as:
Twinkie@squirrel ~/git/t/trash
$ git-apply --check --allow-binary-replacement BF.diff
fatal: patch with only garbage at line 30
could it be an outdated diff? (2.8.7)
[1] Re: "make test" fails with current HEAD @ 9:23PM CST by A Large
Angry SCM
Anything else you want me to bash this Cygwin install against?
- --
John Benes
GPG Fingerprint: D519 25DB BB5C 38FC 9D02 02E7 596D BC50 F880 27FA
"It is not only the living who are killed in war." - Isaac Asimov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBQ31SF2F0oWcU9kCNAQKLUxAAtqOpSCsGSnNz+q9x8gzqaqjCK+mjjUkJ
YJFalTEeNO9/alp3mPGb4kXwhMahyugGqHZzr2Lp5JC0gDSsn5vqF2sxYtB9yvAg
1lg33awy5AI1LkIcbeiCvjkBI83UvIjOYLEs1YcIXKRDYJkcbo6yBN4uqkDZKAoS
O8L3q2r2/mCJQYlANy1ruhT0Al5xPwTFNv6JqIkm8PWsPE+es6ZwyFBXKi62CHu5
AWsc2nHDhPIx5YS1h7CIIQjiRh2qkf807IvXKZtY++o7yoHn49Rtu87VblZhkuH5
UHOSE0gDbT37MbIg6hoZc20kBZIq1s+6e+/FhrFAUrmnny9t7fPaU35gJmPPA63W
KajRKOwChmO6V5scTfgimxxzN4Jlnd+AM8FdxTWCfz6s4FLnnzukwX5T4PbWw6Kg
if8fekhKkPYCLQtAa8Q6Xe5GIZJ5ghVRfAnZWhc4p8OJj6gacwGCk/QX0Rxu6z3r
BF9e7RCyytwDw2Lw87NJFc7AYp4V4uINOAMMxPK0eidHOkkVVzu3eaoB8OIVzh5Q
oAwo+gPpd/PgFldJJu4i9e8bD8/J7cwZ0vpMkRDig9P1ZqFCj9t2+bAVzOgJPb80
4YG/UR4VwVuKyYDeLhCHNLYJBssNXCCkN4+UKuLcNsk6+pXzniPVAc2Wda5BMIj2
LV5oMRUCpKQ=
=NFuc
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: master has some toys
From: John Benes @ 2005-11-18 4:01 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <7vfypur5jb.fsf@assigned-by-dhcp.cox.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Junio C Hamano wrote:
> John Benes <smartcat99s AT gmail DOT com> writes:
>> Commit ID's used for testing:
>> refs/heads/master 4e1da85d7d0480b6d9973317da4f7a5aa603fcb5
>> refs/heads/pu 3b4587eb3c549649af7e84659b4808003c34c2d3
>
> Thanks. But the test result look suspicious for pu.
I verified that I was testing that commit, and the ls-tree results.
Must have been left over after switching from master...
> Anyway, the master is more important at this point.
> So it fails on these binary diffs with full index tests. Could
> you try running it like this?
>
> $ cd t
> $ sh ./t4103-apply-binary.sh -i -v
>
> If all things being equal, this will stop at the first failing
> test "* FAIL 7: ", and you will have trash/ directory under t/.
>
> $ cd trash
> $ ls -l
>
> I would first want to see if it was diff that failed or the
> apply. What does BF.diff contain?
>
Output from the commands requested:
Twinkie@squirrel ~/git/t
$ sh ./t4103-apply-binary.sh -i -v
sh ./t4103-apply-binary.sh -i -v
* expecting success: git-checkout master
git-apply --stat --summary B.diff
file1 | 4 ++--
file2 | 5 -----
file3 | 0
file4 | 0
4 files changed, 2 insertions(+), 7 deletions(-)
delete mode 100644 file2
create mode 100644 file3
* ok 1: stat binary diff -- should not fail.
* expecting success: git-checkout master
git-apply --stat --summary C.diff
file1 | 4 ++--
file2 | 5 -----
file3 | 0
file4 | 0
4 files changed, 2 insertions(+), 7 deletions(-)
delete mode 100644 file2
copy file1 => file3 (70%)
* ok 2: stat binary diff (copy) -- should not fail.
* expecting failure: git-checkout master
git-apply --check B.diff
fatal: patch with only garbage at line 30
* ok 3: check binary diff -- should fail.
* expecting failure: git-checkout master
git-apply --check C.diff
fatal: patch with only garbage at line 32
* ok 4: check binary diff (copy) -- should fail.
* expecting failure: git-checkout master
git-apply --check --allow-binary-replacement B.diff
fatal: patch with only garbage at line 30
* ok 5: check incomplete binary diff with replacement -- should fail.
* expecting failure: git-checkout master
git-apply --check --allow-binary-replacement C.diff
fatal: patch with only garbage at line 32
* ok 6: check incomplete binary diff with replacement (copy) -- should
fail.
* expecting success: git-checkout master
git-apply --check --allow-binary-replacement BF.diff
fatal: patch with only garbage at line 30
* FAIL 7: check binary diff with replacement.
git-checkout master
git-apply --check --allow-binary-replacement BF.diff
Twinkie@squirrel ~/git/t
$ cd trash
cd trash
Twinkie@squirrel ~/git/t/trash
$ ls -l
ls -l
total 19
- -rw-r--r-- 1 Twinkie None 909 Nov 17 21:49 B.diff
- -rw-r--r-- 1 Twinkie None 1173 Nov 17 21:49 BF.diff
- -rw-r--r-- 1 Twinkie None 944 Nov 17 21:49 C.diff
- -rw-r--r-- 1 Twinkie None 1208 Nov 17 21:49 CF.diff
- -rw-r--r-- 1 Twinkie None 201 Nov 17 21:49 file1
- -rw-r--r-- 1 Twinkie None 201 Nov 17 21:49 file2
- -rw-r--r-- 1 Twinkie None 201 Nov 17 21:49 file4
Twinkie@squirrel ~/git/t/trash
$ cat BF.diff
cat BF.diff
diff --git a/file1 b/file1
index
edc575dec543a684da5007b43886ee32ecb381ae..af1eedd35be991f3ced320f7d927799c
72cd8435 100644
- --- a/file1
+++ b/file1
@@ -1,5 +1,5 @@
- -A quick brown fox jumps over the lazy dog.
+A quick brown fov jumps over the lazy dog.
A tiny little penguin runs around in circles.
- -There is a flag with Linux written on it.
+There is a flag with Linuv written on it.
A slow black-and-white panda just sits there,
munching on his bamboo.
diff --git a/file2 b/file2
deleted file mode 100644
index
edc575dec543a684da5007b43886ee32ecb381ae..00000000000000000000000000000000
00000000
- --- a/file2
+++ /dev/null
@@ -1,5 +0,0 @@
- -A quick brown fox jumps over the lazy dog.
- -A tiny little penguin runs around in circles.
- -There is a flag with Linux written on it.
- -A slow black-and-white panda just sits there,
- -munching on his bamboo.
diff --git a/file3 b/file3
new file mode 100644
index
0000000000000000000000000000000000000000..adb07b7ad3fa2c63251b06d1d39cb90a
85b860b4
Files /dev/null and b/file3 differ
diff --git a/file4 b/file4
index
edc575dec543a684da5007b43886ee32ecb381ae..adb07b7ad3fa2c63251b06d1d39cb90a
85b860b4 100644
Files a/file4 and b/file4 differ
Twinkie@squirrel ~/git/t/trash
$ git-apply BF.diff
fatal: patch with only garbage at line 30
- --
John Benes
GPG Fingerprint: D519 25DB BB5C 38FC 9D02 02E7 596D BC50 F880 27FA
"It is not only the living who are killed in war." - Isaac Asimov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBQ31SGGF0oWcU9kCNAQJmchAA0L9fnTvMNwYhDHRVdPyF6XQYJJ7j3s6M
CtcjFvQZ0Zo2tp3ZZ8mqv9ANgPkV80HZFpWPwmlAouFQfNbjvEDlFxLejaKZ5TJj
q068iMk8ZmUUHKPUhONhCsi/toXHQuhA7RMWEwtE9EeugOOIC/++eI8qhKzBhJr3
REzLQN55lqrdhN/6ksrhJQU2VQ3AcAukgezrJy3j8CYOId3pVLYoyD75oxTrelnN
xSPritxM/zkdQZYwx/WeSFRivQQZgiSwm2nREJ5NY5MJ8X5SIZJ+bcHSnndNmUYv
e6YkZRPLXQBAyJpQHwmAQIqtYikPZ/Q6SNBoiQgA3Ws1SyzSaMcOo9R30Cg4LT4i
37EtQwjrGXzY6V/YlHbPqauPlUW6Sosc7fadNXHXkJJrdgyGSATZghh+XEZpNQ1G
2cS05y7/Xu9KnhL0GxbwLf9FZg14CndRh04NDtkdvwyE5rK9SCD5seW6HQOeBcuX
oHLPeA29IaZvHFUYTITXP5p2ZySAXrrFt7R532j6njeJvVCRzV7pPh7msHmAgdXL
Wz5Xv9ED43wz+q6JpXuWloYNyDKUUil2emXVA/MHwLW9ugfZmu9/OVo2ChXf+ZLH
8pSGxRmxTAVSf0GIiODPMWmGrm2zsKbNczCY1wATjiRaYvlmRk1kiXpXpubW5bw9
F1UDCLIFaJk=
=Uh0t
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: master has some toys
From: A Large Angry SCM @ 2005-11-18 3:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Benes, git
In-Reply-To: <7vfypur5jb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> John Benes <smartcat99s@gmail.com> writes:
>
>>Junio C Hamano wrote:
>>
>>I was able to compile master and pu on Cygwin without NO_MMAP=YesPlease
>>in the Cygwin section. However, the make test failed on the
>>binary-apply on both master and pu, output follows.
>>
>>Commit ID's used for testing:
>>refs/heads/master 4e1da85d7d0480b6d9973317da4f7a5aa603fcb5
>>refs/heads/pu 3b4587eb3c549649af7e84659b4808003c34c2d3
>
> Thanks. But the test result look suspicious for pu.
>
> $ git-ls-tree 3b4587eb t | grep t4103
>
> outputs empty, so what you tested does not seem to be that
> commit.
>
> Anyway, the master is more important at this point.
>
>>make test barfing on master:
>>*** t4103-apply-binary.sh ***
>>* FAIL 7: check binary diff with replacement.
>> git-checkout master
>> git-apply --check --allow-binary-replacement BF.diff
>>* FAIL 8: check binary diff with replacement (copy).
>> git-checkout master
>> git-apply --check --allow-binary-replacement CF.diff
>>* FAIL 15: apply binary diff.
>> do_reset
>> git-apply --allow-binary-replacement --index BF.diff &&
>> test -z "$(git-diff --name-status binary)"
>>* FAIL 16: apply binary diff (copy).
>> do_reset
>> git-apply --allow-binary-replacement --index CF.diff &&
>> test -z "$(git-diff --name-status binary)"
>>* failed 4 among 16 test(s)
>>make[1]: *** [t4103-apply-binary.sh] Error 1
>
> So it fails on these binary diffs with full index tests. Could
> you try running it like this?
>
> $ cd t
> $ sh ./t4103-apply-binary.sh -i -v
>
> If all things being equal, this will stop at the first failing
> test "* FAIL 7: ", and you will have trash/ directory under t/.
>
> $ cd trash
> $ ls -l
>
> I would first want to see if it was diff that failed or the
> apply. What does BF.diff contain?
>
OK, here's what I get:
> sh ./t4103-apply-binary.sh -i -v
* expecting success: git-checkout master
git-apply --stat --summary B.diff
file1 | 4 ++--
file2 | 5 -----
file3 | 0
file4 | 0
4 files changed, 2 insertions(+), 7 deletions(-)
delete mode 100644 file2
create mode 100644 file3
* ok 1: stat binary diff -- should not fail.
* expecting success: git-checkout master
git-apply --stat --summary C.diff
file1 | 4 ++--
file2 | 5 -----
file3 | 0
file4 | 0
4 files changed, 2 insertions(+), 7 deletions(-)
delete mode 100644 file2
copy file1 => file3 (70%)
* ok 2: stat binary diff (copy) -- should not fail.
* expecting failure: git-checkout master
git-apply --check B.diff
fatal: patch with only garbage at line 30
* ok 3: check binary diff -- should fail.
* expecting failure: git-checkout master
git-apply --check C.diff
fatal: patch with only garbage at line 32
* ok 4: check binary diff (copy) -- should fail.
* expecting failure: git-checkout master
git-apply --check --allow-binary-replacement B.diff
fatal: patch with only garbage at line 30
* ok 5: check incomplete binary diff with replacement -- should fail.
* expecting failure: git-checkout master
git-apply --check --allow-binary-replacement C.diff
fatal: patch with only garbage at line 32
* ok 6: check incomplete binary diff with replacement (copy) -- should
fail.
* expecting success: git-checkout master
git-apply --check --allow-binary-replacement BF.diff
fatal: patch with only garbage at line 30
* FAIL 7: check binary diff with replacement.
git-checkout master
git-apply --check --allow-binary-replacement BF.diff
> cd trash
internet@Gojira:~/GIT/git/t/trash> ls -l
total 28
-rw-r--r-- 1 internet internet 909 2005-11-17 19:47 B.diff
-rw-r--r-- 1 internet internet 1173 2005-11-17 19:47 BF.diff
-rw-r--r-- 1 internet internet 944 2005-11-17 19:47 C.diff
-rw-r--r-- 1 internet internet 1208 2005-11-17 19:47 CF.diff
-rw-r--r-- 1 internet internet 201 2005-11-17 19:47 file1
-rw-r--r-- 1 internet internet 201 2005-11-17 19:47 file2
-rw-r--r-- 1 internet internet 201 2005-11-17 19:47 file4
> cat BF.diff
diff --git a/file1 b/file1
index
edc575dec543a684da5007b43886ee32ecb381ae..af1eedd35be991f3ced320f7d927799c72cd8435
100644
--- a/file1
+++ b/file1
@@ -1,5 +1,5 @@
-A quick brown fox jumps over the lazy dog.
+A quick brown fov jumps over the lazy dog.
A tiny little penguin runs around in circles.
-There is a flag with Linux written on it.
+There is a flag with Linuv written on it.
A slow black-and-white panda just sits there,
munching on his bamboo.
diff --git a/file2 b/file2
deleted file mode 100644
index
edc575dec543a684da5007b43886ee32ecb381ae..0000000000000000000000000000000000000000
--- a/file2
+++ /dev/null
@@ -1,5 +0,0 @@
-A quick brown fox jumps over the lazy dog.
-A tiny little penguin runs around in circles.
-There is a flag with Linux written on it.
-A slow black-and-white panda just sits there,
-munching on his bamboo.
diff --git a/file3 b/file3
new file mode 100644
index
0000000000000000000000000000000000000000..adb07b7ad3fa2c63251b06d1d39cb90a85b860b4
Files /dev/null and b/file3 differ
diff --git a/file4 b/file4
index
edc575dec543a684da5007b43886ee32ecb381ae..adb07b7ad3fa2c63251b06d1d39cb90a85b860b4
100644
Files a/file4 and b/file4 differ
^ permalink raw reply
* Re: master has some toys
From: Junio C Hamano @ 2005-11-18 3:36 UTC (permalink / raw)
To: John Benes; +Cc: git
In-Reply-To: <437D2D14.5080205@gmail.com>
John Benes <smartcat99s@gmail.com> writes:
> Junio C Hamano wrote:
>
> I was able to compile master and pu on Cygwin without NO_MMAP=YesPlease
> in the Cygwin section. However, the make test failed on the
> binary-apply on both master and pu, output follows.
>
> Commit ID's used for testing:
> refs/heads/master 4e1da85d7d0480b6d9973317da4f7a5aa603fcb5
> refs/heads/pu 3b4587eb3c549649af7e84659b4808003c34c2d3
Thanks. But the test result look suspicious for pu.
$ git-ls-tree 3b4587eb t | grep t4103
outputs empty, so what you tested does not seem to be that
commit.
Anyway, the master is more important at this point.
> make test barfing on master:
> *** t4103-apply-binary.sh ***
> * FAIL 7: check binary diff with replacement.
> git-checkout master
> git-apply --check --allow-binary-replacement BF.diff
> * FAIL 8: check binary diff with replacement (copy).
> git-checkout master
> git-apply --check --allow-binary-replacement CF.diff
> * FAIL 15: apply binary diff.
> do_reset
> git-apply --allow-binary-replacement --index BF.diff &&
> test -z "$(git-diff --name-status binary)"
> * FAIL 16: apply binary diff (copy).
> do_reset
> git-apply --allow-binary-replacement --index CF.diff &&
> test -z "$(git-diff --name-status binary)"
> * failed 4 among 16 test(s)
> make[1]: *** [t4103-apply-binary.sh] Error 1
So it fails on these binary diffs with full index tests. Could
you try running it like this?
$ cd t
$ sh ./t4103-apply-binary.sh -i -v
If all things being equal, this will stop at the first failing
test "* FAIL 7: ", and you will have trash/ directory under t/.
$ cd trash
$ ls -l
I would first want to see if it was diff that failed or the
apply. What does BF.diff contain?
^ permalink raw reply
* Re: "make test" fails with current HEAD
From: Johannes Schindelin @ 2005-11-18 3:27 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Matthias Urlichs, git
In-Reply-To: <437D4924.50307@gmail.com>
Hi,
On Thu, 17 Nov 2005, A Large Angry SCM wrote:
> Fails at home (Suse 9.3) but passes a work (Ubuntu Hoary).
>
> *** t4103-apply-binary.sh ***
> * ok 1: stat binary diff -- should not fail.
> * ok 2: stat binary diff (copy) -- should not fail.
> * ok 3: check binary diff -- should fail.
> * ok 4: check binary diff (copy) -- should fail.
> * ok 5: check incomplete binary diff with replacement -- should fail.
> * ok 6: check incomplete binary diff with replacement (copy) -- should fail.
> * FAIL 7: check binary diff with replacement.
> git-checkout master
> git-apply --check --allow-binary-replacement BF.diff
Any chance you investigate this in detail? Like inserting "test_done;
exit" right before that test, only running t4103-*, and then executing
the command yourself?
Hth,
Dscho
^ permalink raw reply
* Re: "make test" fails with current HEAD
From: A Large Angry SCM @ 2005-11-18 3:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthias Urlichs, git
In-Reply-To: <Pine.LNX.4.63.0511171652020.17402@wbgn013.biozentrum.uni-wuerzburg.de>
Fails at home (Suse 9.3) but passes a work (Ubuntu Hoary).
*** t4103-apply-binary.sh ***
* ok 1: stat binary diff -- should not fail.
* ok 2: stat binary diff (copy) -- should not fail.
* ok 3: check binary diff -- should fail.
* ok 4: check binary diff (copy) -- should fail.
* ok 5: check incomplete binary diff with replacement -- should fail.
* ok 6: check incomplete binary diff with replacement (copy) -- should
fail.
* FAIL 7: check binary diff with replacement.
git-checkout master
git-apply --check --allow-binary-replacement BF.diff
* FAIL 8: check binary diff with replacement (copy).
git-checkout master
git-apply --check --allow-binary-replacement CF.diff
* ok 9: apply binary diff -- should fail.
* ok 10: apply binary diff -- should fail.
* ok 11: apply binary diff (copy) -- should fail.
* ok 12: apply binary diff (copy) -- should fail.
* ok 13: apply binary diff without replacement -- should fail.
* ok 14: apply binary diff without replacement (copy) -- should fail.
* FAIL 15: apply binary diff.
do_reset
git-apply --allow-binary-replacement --index BF.diff &&
test -z "$(git-diff --name-status binary)"
* FAIL 16: apply binary diff (copy).
do_reset
git-apply --allow-binary-replacement --index CF.diff &&
test -z "$(git-diff --name-status binary)"
* failed 4 among 16 test(s)
make[1]: *** [t4103-apply-binary.sh] Error 1
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 17 Nov 2005, Matthias Urlichs wrote:
>
>>t4103.sh:
>>
>>fatal: patch with only garbage at line 30
>>* FAIL 7: check binary diff with replacement.
>> git-checkout master
>> git-apply --check --allow-binary-replacement BF.diff
>
> Does not fail here.
>
> Did you set your GIT_EXEC_PATH?
>
> Hth,
> Dscho
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Teach "approxidate" about weekday syntax
From: Johannes Schindelin @ 2005-11-18 2:53 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <46a038f90511171740x756b0336ib8b8937ee3a2af03@mail.gmail.com>
Hi,
On Fri, 18 Nov 2005, Martin Langhoff wrote:
> On 11/18/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Thu, 17 Nov 2005, Linus Torvalds wrote:
> > > Seriously, I can't imagine what else we'd want.
> > An error when there's a chance the result is unexpected?
>
> That'd be even harder to define -- I'd rather have it spit out what it
> interpreted so that porcelains can display it to the user. The user
> can tell at a glance if the parser is off -- for it will be off by a
> mile.
Yes, it may be off by a mile. But if there exists a feature to specify a
date that comfortably, people don't RTFM, but use it.
Now comes the rub: if nothing is displayed, they take it that everything
was fine. *If* something was displayed, one knew that the code parsed
yesterday when last year was meant. But *if not*, nobody knows.
This is dangerous. It is wrong, but does not say so.
Hth,
Dscho
^ permalink raw reply
* Re: master has some toys
From: Johannes Schindelin @ 2005-11-18 2:48 UTC (permalink / raw)
To: John Benes; +Cc: Junio C Hamano, git
In-Reply-To: <437D2D14.5080205@gmail.com>
Hi,
On Thu, 17 Nov 2005, John Benes wrote:
> I was able to compile master and pu on Cygwin without NO_MMAP=YesPlease
> in the Cygwin section. However, the make test failed on the
> binary-apply on both master and pu, output follows.
Nobody doubts that you can *compile* it. The problem is the fixing of the
mmap()ed regions after fork(). Since win32 is such a sane system, it does
not provide mmap() or fork() out of the box. And under some very obscure
circumstances, cygwin's emulation of mmap() and fork() fails.
BTW, it would be more helpful if you do not just tell *what* test fails,
but *how*. For example, try to run "git-whatchanged -p" and send just
the first page of the output (both stdout and stderr). I bet it says it
has a problem fixing up mmap() after fork().
Hth,
Dscho
^ permalink raw reply
* Re: Teach "approxidate" about weekday syntax
From: Linus Torvalds @ 2005-11-18 2:38 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <46a038f90511171740x756b0336ib8b8937ee3a2af03@mail.gmail.com>
On Fri, 18 Nov 2005, Martin Langhoff wrote:
>
> That'd be even harder to define -- I'd rather have it spit out what it
> interpreted so that porcelains can display it to the user. The user
> can tell at a glance if the parser is off -- for it will be off by a
> mile.
Well, quite frankly, almost always it's pretty damn obvious.
We could make it less so: the most common mistake when it doesn't parse
sanely is that it doesn't parse anything at all, but it saw a number
somewhere, and thought it was a day of the month.
For example, "last janurary" will silently parse to just "1" (miss-spelled
"january"), which will be interpreted as the "first of this month".
And we could make _that_ be an error. If you want the first of this month,
you'd have to spell out the month, ie write "Nov 1" instead of just "1".
Apart from that parsign error, pretty much everything else will tend to
parse correctly or just give "now" (which is pretty obvious when you ask
for a log "since now", and get an empty answer back).
But quite frankly, I don't think the approximate date-parsing is serious
enough to even worry about these kinds of things. I actually use it, but I
don't think anybody _depends_ on it. It's useful to do
gitk --since=last.week
just as a way to speed up the startup (if you're just interested in the
top of the tree, the kernel history is so big that it's just pointless to
do a full gitk, and doing the "since last week" is a quick way to just
limit the history enough that it makes the graph cleaner).
And if you get that wrong, who cares? It's not a big deal. The approxidate
parsing is one of those "hey, that's nice" features, but it's definitely
not important.
Linus
^ permalink raw reply
* Re: Teach "approxidate" about weekday syntax
From: Martin Langhoff @ 2005-11-18 1:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0511180030260.18775@wbgn013.biozentrum.uni-wuerzburg.de>
On 11/18/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 17 Nov 2005, Linus Torvalds wrote:
> > Seriously, I can't imagine what else we'd want.
> An error when there's a chance the result is unexpected?
That'd be even harder to define -- I'd rather have it spit out what it
interpreted so that porcelains can display it to the user. The user
can tell at a glance if the parser is off -- for it will be off by a
mile.
m
^ permalink raw reply
* Re: master has some toys
From: John Benes @ 2005-11-18 1:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtj7wn7n.fsf@assigned-by-dhcp.cox.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Junio C Hamano wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>> As it turned out, not the git.c is guilty, but the missing
>> NO_MMAP=YesPlease in Cygwin section. I had it for a long time and
>> accidentally removed by the recent pull. BTW, I couldn't find nowhere
>> on original branch. Was it never submitted?
>
> Neither 'git-whatchanged Makefile' nor 'git-whatchanged
> -SNO_MMAP Makefile' reports such on my end. Do we need one?
The patch with the commented out option seems like it would work...
> Johannes said he tests on Cygwin as well, and I am sure there
> are others with Cygin on the list. Help us out here please?
I was able to compile master and pu on Cygwin without NO_MMAP=YesPlease
in the Cygwin section. However, the make test failed on the
binary-apply on both master and pu, output follows.
Commit ID's used for testing:
refs/heads/master 4e1da85d7d0480b6d9973317da4f7a5aa603fcb5
refs/heads/pu 3b4587eb3c549649af7e84659b4808003c34c2d3
make test barfing on master:
*** t4103-apply-binary.sh ***
* ok 1: stat binary diff -- should not fail.
* ok 2: stat binary diff (copy) -- should not fail.
* ok 3: check binary diff -- should fail.
* ok 4: check binary diff (copy) -- should fail.
* ok 5: check incomplete binary diff with replacement -- should fail.
* ok 6: check incomplete binary diff with replacement (copy) -- should
fail.
* FAIL 7: check binary diff with replacement.
git-checkout master
git-apply --check --allow-binary-replacement BF.diff
* FAIL 8: check binary diff with replacement (copy).
git-checkout master
git-apply --check --allow-binary-replacement CF.diff
* ok 9: apply binary diff -- should fail.
* ok 10: apply binary diff -- should fail.
* ok 11: apply binary diff (copy) -- should fail.
* ok 12: apply binary diff (copy) -- should fail.
* ok 13: apply binary diff without replacement -- should fail.
* ok 14: apply binary diff without replacement (copy) -- should fail.
* FAIL 15: apply binary diff.
do_reset
git-apply --allow-binary-replacement --index BF.diff &&
test -z "$(git-diff --name-status binary)"
* FAIL 16: apply binary diff (copy).
do_reset
git-apply --allow-binary-replacement --index CF.diff &&
test -z "$(git-diff --name-status binary)"
* failed 4 among 16 test(s)
make[1]: *** [t4103-apply-binary.sh] Error 1
make test barfing on pu:
*** t4103-apply-binary.sh ***
usage: git-diff-tree [--stdin] [-m] [-s] [-v] [--pretty] [-t] [-r]
[--root] [<co
mmon diff options>] <tree-ish> [<tree-ish>] [<path>...]
***SNIP***
usage: git-diff-tree [--stdin] [-m] [-s] [-v] [--pretty] [-t] [-r]
[--root] [<co
mmon diff options>] <tree-ish> [<tree-ish>] [<path>...]
***SNIP***
* FAIL 1: stat binary diff -- should not fail.
git-checkout master
git-apply --stat --summary B.diff
* FAIL 2: stat binary diff (copy) -- should not fail.
git-checkout master
git-apply --stat --summary C.diff
* ok 3: check binary diff -- should fail.
* ok 4: check binary diff (copy) -- should fail.
* ok 5: check incomplete binary diff with replacement -- should fail.
* ok 6: check incomplete binary diff with replacement (copy) -- should
fail.
* FAIL 7: check binary diff with replacement.
git-checkout master
git-apply --check --allow-binary-replacement BF.diff
* FAIL 8: check binary diff with replacement (copy).
git-checkout master
git-apply --check --allow-binary-replacement CF.diff
* ok 9: apply binary diff -- should fail.
* ok 10: apply binary diff -- should fail.
* ok 11: apply binary diff (copy) -- should fail.
* ok 12: apply binary diff (copy) -- should fail.
* ok 13: apply binary diff without replacement -- should fail.
* ok 14: apply binary diff without replacement (copy) -- should fail.
* FAIL 15: apply binary diff.
do_reset
git-apply --allow-binary-replacement --index BF.diff &&
test -z "$(git-diff --name-status binary)"
* FAIL 16: apply binary diff (copy).
do_reset
git-apply --allow-binary-replacement --index CF.diff &&
test -z "$(git-diff --name-status binary)"
* failed 6 among 16 test(s)
make[1]: *** [t4103-apply-binary.sh] Error 1
- --
John Benes
GPG Fingerprint: D519 25DB BB5C 38FC 9D02 02E7 596D BC50 F880 27FA
"It is not only the living who are killed in war." - Isaac Asimov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBQ30tE2F0oWcU9kCNAQKzRQ/8DEoZTRYDcU80mzddq8AS8ClctLx8CorY
OJYY/sTAivjot7R/bPUj97Ie+FaUKC0mpTOGZTT8KkSpRg2mbZ6YlTUoHAtf4iq3
F9vQs2qVJqyUJqbXcP+X68huIZF7vHZI47e9ExTO1RrxZCGxDp8JigfhmlS4CN4K
Dee1NSMnoWGklNEXvZMwkvhLerV+9Xs6UTGZ5AeRHRiHiLqK+I9eDNaULABHwAYO
JSsat0HDjKMKrgNNFo43TpRTm17gq7N83LOJJkxiNYnRPh8nGpIOgfNx8riWP5DB
tMw3FWvA9bv3tllvTFC4wx92Rgfs255cvXEunqfRTsMzGG7rhdg4UY92I0yB8k6b
g6nucu93VtwEkHZ1b9ZTBwz85ZuTImS/72pHbRPvOaeSuDArBI9i+Lwrb+z+0vUS
iMMuAxtWhKUFr87A6ljdu27IfE+pJaEgGEySGkquU3EexuNRMz62raveRsEpLSu8
iqbKoMeC1A7CtcbV3OBdktfFyM3rR8/G9OpjBNdkojo08BOvsoMCU45jLdXFIFtu
MGMajhGEu8EwAdItq6Qq0fXOfU6ph5oN4tg1pKt83QDkDFJyEJzOH1CMLh+qxXR3
m25wLSJcV8YbNfQVMumw2aFXn3ojwkP3kEheoTKexTFVkwGS0dU/j9kpQ8wj9Pqv
1ttxTdlX2HM=
=OthK
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 5/5] git-daemon support for user-relative paths.
From: Junio C Hamano @ 2005-11-18 0:49 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <20051117193714.428785C7FA@nox.op5.se>
exon@op5.se (Andreas Ericsson) writes:
> Everything that worked earlier still works insofar as I have
> remembered testing it.
Hmph...
> @@ -152,45 +140,17 @@ static int set_dir(const char *dir)
> * We want a readable HEAD, usable "objects" directory, and
> * a "git-daemon-export-ok" flag that says that the other side
> * is ok with us doing this.
Well, not anymore about HEAD as far as I can tell... Maybe in
enter_repo ([PATCH 1/5]) we need to do something like what
setup.c::is_toplevel_directory() does?
> -static int upload(char *dir)
> -{
> - /* Try paths in this order */
> - static const char *paths[] = { "%s", "%s/.git", "%s.git", "%s.git/.git", NULL };
I think this list was added relatively recently as a usability
measure. Maybe we would want an equivalent in enter_repo()?
Under strict-path, I think not doing any DWIM like this is fine,
but otherwise I suspect changing this would break existing
remotes/origin file people may have. In addition enter_repo()
as posted does its own DWIM to chdir to ".git" unconditionally
as I pointed out...
Needs a bit more thought, but I think otherwise the basic idea
is right.
^ permalink raw reply
* Re: [PATCH] Add .git/version
From: Junio C Hamano @ 2005-11-18 0:49 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0511171131260.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> My one argument against this is that I don't see why we have to have a
> separate file for this.
True.
> Why not just add a "core.version" flag to the config file?
True, perhaps core.repository-format-version?
^ permalink raw reply
* Re: [PATCH 1/5] Library code for user-relative paths, take three.
From: Junio C Hamano @ 2005-11-17 23:56 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <20051117193714.2B8995BF93@nox.op5.se>
exon@op5.se (Andreas Ericsson) writes:
> + if(strict && *dir != '/')
(style everywhere)
if (strict ...
> + /* This is perfectly safe, and people tend to think of the directory
> + * where they ran git-init-db as their repository, so humour them. */
> + (void)chdir(".git");
It might be safe, but I think it changes the behaviour of
upload-pack with strict case. My gut reaction is we would want
"if (!strict)" in front. Thoughts?
^ permalink raw reply
* Re: [PATCH] Add .git/version
From: Johannes Schindelin @ 2005-11-17 23:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Josef Weidendorfer, git, Martin Atukunda
In-Reply-To: <Pine.LNX.4.64.0511171131260.13959@g5.osdl.org>
Hi,
On Thu, 17 Nov 2005, Linus Torvalds wrote:
> On Thu, 17 Nov 2005, Junio C Hamano wrote:
> >
> > - We want repository-format-version but that may be too
> > long. Just saying version is a bit confusing. Abbreviating
> > it to repository-version makes it sound as if somebody took a
> > snapshot (i.e. tar-tree $commit). Whatever name we choose,
> > let's pick a one not so confusing.
>
> My one argument against this is that I don't see why we have to have a
> separate file for this.
>
> Why not just add a "core.version" flag to the config file? If no version
> exists, assume it's version 1. And then, if we ever start using some other
> version, make git-init-db always create the config file (the way we
> already do for "core.filemode")
Note that git-sh-setup and setup_git_directory() should check for it and
complain if it finds a value > 1. Else there is not much which prevents
old tools (like current) to access future versions.
The actual number may come later. The check can't.
Ciao,
Dscho
^ permalink raw reply
* Re: master has some toys
From: Johannes Schindelin @ 2005-11-17 23:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vveyrt6ms.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 17 Nov 2005, Junio C Hamano wrote:
> + # There are conflicting reports about this.
> + # On some boxes NO_MMAP is needed, and not so elsewhere.
> + # Try uncommenting this if you see things break -- YMMV.
> + # NO_MMAP = YesPlease
Sounds sensible. Maybe you want to output that to stderr or stdout?
Ciao,
Dscho
^ permalink raw reply
* Re: Teach "approxidate" about weekday syntax
From: Johannes Schindelin @ 2005-11-17 23:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0511171505080.13959@g5.osdl.org>
Hi,
On Thu, 17 Nov 2005, Linus Torvalds wrote:
> Seriously, I can't imagine what else we'd want.
An error when there's a chance the result is unexpected?
Ciao,
Dscho
^ permalink raw reply
* Re: Teach "approxidate" about weekday syntax
From: Linus Torvalds @ 2005-11-17 23:30 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <437D0FC8.6000906@zytor.com>
On Thu, 17 Nov 2005, H. Peter Anvin wrote:
>
> I believe English would always parse from right to left, it might be the right
> thing to do...
I'll try if that makes any difference. It would have some other advantages
(ie it would make it easy to actually differentiate between "ago" and
"from now").
Linus
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Johannes Schindelin @ 2005-11-17 23:28 UTC (permalink / raw)
To: Yann Dirson; +Cc: Ryan Anderson, git
In-Reply-To: <20051117230723.GD26122@nowhere.earth>
Hi,
On Fri, 18 Nov 2005, Yann Dirson wrote:
> Current commit objects refer to a child tree, but to parent _commits_.
> Whereas it seems necessary to walk through the history line, and
> easily get a changelog, it is semantically quite not right:
Yes, it is. You base *your* work on *some* work. So, even if the trees may
be equal, the base isn't.
> Indeed that emphasizes that the history lines are on living on a
> higher level of abstraction that commits. Now what if we used
> trees->tree commits, instead of the current commits->tree ones ?
Now, how exactly would that be more abstract? Trees are just that:
collections of files. Noone tells you what the idea was, which led from
the last tree(s) to this one. That is not abstract.
> Any genius with a solution out there ? :)
Not a genius, but me: Write down your ideas in the commit message. That it
the place to put abstract thoughts into.
Ciao,
Dscho
^ permalink raw reply
* Re: Add git-config-set, a simple helper for scripts to set config variables
From: Johannes Schindelin @ 2005-11-17 23:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vveyqswzx.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 17 Nov 2005, Junio C Hamano wrote:
> It's kinda funny that your users cannot edit a plain text file
> with an editor, but know how to do regex ;-).
No, they can't. But they deem it a cool feature... FDM...
Ciao,
Dscho
^ permalink raw reply
* Re: Teach "approxidate" about weekday syntax
From: Linus Torvalds @ 2005-11-17 23:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511171505080.13959@g5.osdl.org>
On Thu, 17 Nov 2005, Linus Torvalds wrote:
>
> I think I'm done.
The only thing I might want to do is add some support for time-of-day to
the thing. Notably "noon" and "midnight".
Linus
^ permalink raw reply
* Re: git rebase conflict help?
From: Junio C Hamano @ 2005-11-17 23:21 UTC (permalink / raw)
To: Kevin Geiss; +Cc: git
In-Reply-To: <33D6F7FB-7864-471B-A111-9991C768577A@desertsol.com>
Kevin Geiss <kevin@desertsol.com> writes:
> I fetched my origin branch, then tried to run 'git rebase origin'.
> one of my commits from master which is not yet in origin got a
> conflict, so git rebase origin told me that the Simple cherry-pick
> failed, and the Automatic cherry-pick got conflicts. and it saved the
> commit message for me in .msg and my offending commit's id in .rebase-
> tmp32409.
Sorry, the tool support for this situation is very poor in the
original rebase code.
With the tool you have, you need to make sure that the working
tree matches the (halfway) rebased master's head, and run
"git-cherry-pick --replay $commit" on the offending commits
stored in .rebase-tmp$$, one by one.
^ permalink raw reply
* Re: Teach "approxidate" about weekday syntax
From: Linus Torvalds @ 2005-11-17 23:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1x1eubpr.fsf@assigned-by-dhcp.cox.net>
On Thu, 17 Nov 2005, Junio C Hamano wrote:
>
> It is not English but Gittish, which is fine, but it somehow
> reminds me of the funny way users make themselves understood by
> IF parsers ;-). I am afraid you started small but now are going
> towards the same insanity of gnudate (it has insane yacc grammar
> to grok these things), and I suspect we'd better draw a line
> somewhere.
I think I'm done.
The multi-week "3 sundays ago" part came for free, but the "last sunday"
was actually something I liked.
Seriously, I can't imagine what else we'd want. It parses exact dates
(thanks to the old date-parsing code), and it now parses all the normal
"lazy dates" I can think of.
The fact that you can combine "last saturday" with "three days ago" is
really not a feature as much as a result of the algorithm being so simple
that it just doesn't care, and the combination just happens to work.
My examples were a bit silly as a result. In real life, you'd probably
never use any combinations, but simply use
"December 5th"
"last sunday"
"yesterday"
"two days ago"
"12 hours ago"
and the fact that then some (but definitely not all) combinations of the
above all work is really just an accident and not something that people
should necessarily even depend on.
> > Side note 2: if you want to avoid spaces (because of quoting issues), you
> > can use any non-alphanumberic character instead. So
> >
> > git log --since=2.days.ago
> >
> > works without any quotes.
>
> I think this is a useful change. Thanks.
That's actually not a new change, the approxidate thing always worked that
way, but I thought I'd point it out.
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox