# gits...@pobox.com / 2014-09-12 10:31:30 -0700:
Roman Neuhauser neuhau...@sigpipe.cz writes:
git-diff-tree without --root is absolutely silent for the root commit,
and i see no bad effects of --root on non-root commits. are there any
hidden gotchas? IOW, why is the --root behavior
Hello,
I have spotted a problem using 'git diff' when non ascii characters are
involved.
Not sure if the problem is due to the name of the file, or its content.
Cheers,
Giulio Cesare
Steps to reproduce the problem:
$ sw_vers
ProductName:Mac OS X
ProductVersion: 10.9.4
BuildVersion
hello,
git-diff-tree without --root is absolutely silent for the root commit,
and i see no bad effects of --root on non-root commits. are there any
hidden gotchas? IOW, why is the --root behavior not the default?
cram[1] testcase::
$ git init -q scratch
$ cd scratch
$ echo '.*.sw
Roman Neuhauser neuhau...@sigpipe.cz writes:
git-diff-tree without --root is absolutely silent for the root commit,
and i see no bad effects of --root on non-root commits. are there any
hidden gotchas? IOW, why is the --root behavior not the default?
Because tools that was written before
On 2014-09-12 08.53, Giulio Cesare Solaroli wrote:
Hello,
I have spotted a problem using 'git diff' when non ascii characters are
involved.
Not sure if the problem is due to the name of the file, or its content.
Cheers,
Giulio Cesare
Steps to reproduce the problem:
$ sw_vers
Hello,
Today, while redirecting git diff's output to a text file, I noticed git diff
leaves a trailing whitespace between different deltas of the same file (the line
that separates two different deltas). For example, committing a file with the
following content:
---
test
test
---
then changing
On Tue, Jul 29, 2014 at 11:06:25AM +1000, Bryan Turner wrote:
On Tue, Jul 29, 2014 at 10:11 AM, Junio C Hamano gits...@pobox.com wrote:
OK, I pushed out updated 'maint' and 'master'. The former merges
a rebased version of jk/alloc-commit-id in to make the reorganize
the way we manage the
Using git diff-tree --stdin on 2.0.2 and 2.0.3 produces incorrect
commit messages.
Here's an example to reproduce the issue:
bturner@ubuntu:/tmp$ git init --bare test.git
Initialized empty Git repository in /tmp/test.git/
bturner@ubuntu:/tmp$ git clone test.git
Cloning into 'test'...
warning
On 28/07/14 10:42, Bryan Turner wrote:
Using git diff-tree --stdin on 2.0.2 and 2.0.3 produces incorrect
commit messages.
Here's an example to reproduce the issue:
bturner@ubuntu:/tmp$ git init --bare test.git
Initialized empty Git repository in /tmp/test.git/
bturner@ubuntu:/tmp$ git
On Mon, Jul 28, 2014 at 07:42:16PM +1000, Bryan Turner wrote:
Running a git bisect between v2.0.1, which does not manifest this
issue, and v2.0.2 fingers the following commit:
bturner@ubuntu:~/Development/oss/git/git$ git bisect bad
c1b3c71f4b4571abb2b2a457122fd100dc9f7eb0 is the first bad
in jk/alloc-commit-id should fix the problem
(it's in master already, and slated for v2.1.0).
Yep, that's definitely it. Here's the minimum reproduction:
git init
git commit --allow-empty -m one
git commit --allow-empty -m two
git rev-list HEAD | git diff-tree --stdin --always --format=%s
git rev-list HEAD | git diff-tree --stdin --always --format=%s
That yields:
one
one
on v2.0.3, but merging in jk/alloc-commit-id yields:
two
one
-Peff
Thanks for digging into it, Jeff. I should have tried it against 2.1.0
myself. I've run my entire matrix of tests now
Bryan Turner btur...@atlassian.com writes:
It looks like refs ending in a dot are now legal in 2.1.0? Is that
intentional? A quick git bisect is fingering:
bturner@ubuntu:~/Development/oss/git/git$ git bisect bad
745224e04a03e4544c58d5d38d3c54f67100f8eb is the first bad commit
commit
On Mon, Jul 28, 2014 at 08:35:52AM -0700, Junio C Hamano wrote:
I am tempted to revert that series; it already caused oops, this
needs a further fix before it hit 'master' at least once, and we do
not want any more headaches at this point in the release cycle.
Yeah, that sounds reasonable to
Jeff King p...@peff.net writes:
On Mon, Jul 28, 2014 at 07:42:16PM +1000, Bryan Turner wrote:
Running a git bisect between v2.0.1, which does not manifest this
issue, and v2.0.2 fingers the following commit:
bturner@ubuntu:~/Development/oss/git/git$ git bisect bad
On Mon, Jul 28, 2014 at 10:32:45AM -0700, Junio C Hamano wrote:
Junio, we should consider a v2.0.4 with that series, I think. This is a
pretty serious regression in diff-tree (I didn't even realize that the
buffer-slab work went into the maint series; that may have been a little
-- file on unborn
branch' '
test_cmp $TEST_DIRECTORY/t4013/diff.diff_--cached_--_file0 result
'
+test_expect_success 'diff-tree --stdin with log formatting' '
+ cat expect -\EOF
+ Side
+ Third
+ Second
+ EOF
+ git rev-list master | git diff-tree
/diff.diff_--cached_--_file0 result
'
+test_expect_success 'diff-tree --stdin with log formatting' '
+ cat expect -\EOF
+ Side
+ Third
+ Second
+ EOF
+ git rev-list master | git diff-tree --stdin --format=%s -s actual
+ test_cmp expect actual
+'
+
test_done
Junio C Hamano gits...@pobox.com writes:
Yeah, I'm fine with a straight revert, too (I think it is fine to keep
in master, though). I think jk/alloc-commit-id is built right on top of
the original commit-slab topic, so it should be easy to do either way.
Thanks for dealing with it.
On Tue, Jul 29, 2014 at 10:11 AM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Yeah, I'm fine with a straight revert, too (I think it is fine to keep
in master, though). I think jk/alloc-commit-id is built right on top of
the original commit-slab topic, so
(I am on the list cc not needed)
jpyeron@black /projects/cipherShed
$ git --version uname -a
git version 1.8.4.21.g992c386
CYGWIN_NT-5.2-WOW64 black 1.7.30(0.272/5/3) 2014-05-23 10:36 i686 Cygwin
jpyeron@black /projects/cipherShed
$ git diff src/Format/Format.vcproj
diff --git a/src/Format
diff | head -3
diff --git i/x w/x
index 257cc56..5716ca5 100644
--- i/x
% git diff --dst-prefix=// | head -3
diff --git i/x //x
The feature these options implement was never designed to accept
anything other than foo/bar/ (i.e. a relative path-looking thing
that ends with / and no funnies
% git init
Initialized empty Git repository in /home/npostavs/tmp/scratch/.git/
% echo foo x
% git add x
% git commit -m x
[master (root-commit) 41be1f2] x
1 file changed, 1 insertion(+)
create mode 100644 x
% echo bar x
% git diff | head -3
diff --git i/x w/x
index 257cc56..5716ca5 100644
Hi,
I get an unexpected behaviour for git diff --word-diff if 2 adjacent lines
start and end with the same letter. I tried versions 1.7.9 and 1.9.0.
Attached is a script with 7 examples. For each example, a file with 2 lines is
compared to a file with the same lines, only 1 or 2 letters appended
Matthieu Moy matthieu@grenoble-inp.fr writes:
rocketscienc01100101 . rocketscienc01100...@gmail.com writes:
http://i.imgur.com/BoJSjm9.png
Here's a screenshot that shows the problem.
(better cut-and-paste the text than sending a PNG image)
There's always a misplaced line in the
rocketscienc01100101 . rocketscienc01100...@gmail.com writes:
http://i.imgur.com/BoJSjm9.png
Here's a screenshot that shows the problem.
(better cut-and-paste the text than sending a PNG image)
There's always a misplaced line in the output (most of the time
a[href^=tel] { }), no matter
I tried to get a diff between HEAD and the current version of my
project, so I did git diff.
It's a web project with a CSS file that contains the following CSS rule:
a[href^=tel] {
color:inherit;
text-decoration:none;
}
Now, whenever I do git diff, it will always show the a[href^=tel
On Tue, Apr 01, 2014 at 12:49:00PM +0200, rocketscienc01100101 . wrote:
I tried to get a diff between HEAD and the current version of my
project, so I did git diff.
That actually diffs between the index and the working tree, but if you
haven't used git add to add any changes, the index content
I hit this oddity when not remembering the right syntax for --color-words..
Try this (outside of a git repository):
touch a b
git diff -u --color=words a b
and watch it scroll (infinitely) printing out
error: option `color' expects always, auto, or never
forever.
I haven't tried
Linus Torvalds torva...@linux-foundation.org writes:
I hit this oddity when not remembering the right syntax for --color-words..
Try this (outside of a git repository):
touch a b
git diff -u --color=words a b
and watch it scroll (infinitely) printing out
error: option `color
On Mon, Mar 31, 2014 at 11:30 AM, Junio C Hamano gits...@pobox.com wrote:
Hmph, interesting. outside a repository is the key, it seems.
Well, you can do it inside a repository too, but then you need to use
the --no-index flag to get the diff two files behavior. It will
result in the same
Junio C Hamano gits...@pobox.com writes:
Linus Torvalds torva...@linux-foundation.org writes:
I hit this oddity when not remembering the right syntax for --color-words..
Try this (outside of a git repository):
touch a b
git diff -u --color=words a b
and watch it scroll (infinitely
Mail von Stefan-W. Hahn, Sun, 09 Feb 2014 at 12:01:55 +0100:
Good afternoon,
I updated the test a little bit. Test 3 and 7 are going wrong.
Both tests have a CRLF line ending in the changed line.
I you redirect the output of the test to a file you see the main
problem:
,
|
:56 AM.
| Please zip the attachment and send it again. If you have any questions,
| please contact IT. Thank you
|
| Message details:
| Server: ATLOWA1
| Sender: stefan.h...@s-hahn.de;
| Recipient: git@vger.kernel.org;
| Subject: Re: Bug: Problem with CRLF line ending in git-diff with coloring
the files as I wish.
I'm confused. This setting does not change your files, but instructs git
diff and git apply to not report the trailing CR as white-space error.
Didn't you try it?
-- Hannes
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
have files of both sorts (mainly
C/C++) files in my repository and cannot change the files as I wish.
I'm confused. This setting does not change your files, but instructs git
diff and git apply to not report the trailing CR as white-space error.
Didn't you try it?
You are right, if I configure
Good morning,
when diffing output where files have CRLF line ending, the coloring
seems wrong, because in changed lines the CR (^M) is highlighted,
even if the line ending has not changed.
The diff engine itself is correct.
I added a test case to show this behaviour.
The problem seems to come
Am 09.02.2014 12:01, schrieb Stefan-W. Hahn:
Good morning,
when diffing output where files have CRLF line ending, the coloring
seems wrong, because in changed lines the CR (^M) is highlighted,
even if the line ending has not changed.
...
If WS_CR_AT_EOL is set in ecbdata-ws_rule, it works
The fragment of 'git diff' output looks like this:
- translationОшибка: адрес %1 содержит запрещенные символы.
Пожалуйста, перепро�
+ translationОшибка: адрес %1 содержит запрещённые символы.
Пожалуйста, перепро�
Two issues here:
1. Cyrilic text in utf8 got truncated not at utf8 boundary
On Thu, Jan 23, 2014 at 11:45:25AM +0900, IWAMOTO Toshihiro wrote:
I found git-diff --quiet returns a zero exit status even if there's
a change. The following sequence reproduces the bug:
$ mkdir foo
$ cd foo
$ git init
$ echo a a.txt
$ echo b b.txt
$ git add ?.txt
$ git
On Sat, Jan 25, 2014 at 10:34 AM, Yuri y...@rawbw.com wrote:
The fragment of 'git diff' output looks like this:
- translationОшибка: адрес %1 содержит запрещенные символы. Пожалуйста,
перепро�
+ translationОшибка: адрес %1 содержит запрещённые символы. Пожалуйста,
перепро�
Two issues here
I found git-diff --quiet returns a zero exit status even if there's
a change. The following sequence reproduces the bug:
$ mkdir foo
$ cd foo
$ git init
$ echo a a.txt
$ echo b b.txt
$ git add ?.txt
$ git commit
$ echo b b.txt
$ touch a.txt
$ git diff --quiet; echo
Hi,
I just did a rebase, and it throws an error like this:
Applying: comment1
Applying: comment2
Applying: comment3
Applying: comment4
Applying: patch_with_binary_files
fatal: git diff header lacks filename information when removing 1
leading pathname component (line 7330213)
Repository lacks
On 14 January 2014 12:48, demerphq demer...@gmail.com wrote:
Hi,
I just did a rebase, and it throws an error like this:
Applying: comment1
Applying: comment2
Applying: comment3
Applying: comment4
Applying: patch_with_binary_files
fatal: git diff header lacks filename information when
+ a.h
+ b.c
+ EOF
+
+ cat expect_2 -\EOF
+ c/Makefile
+ a.h
+ b.c
+ d.txt
+ EOF
+
+ true# end chain of
+'
+
+test_expect_success no order (=tree object order) '
+ git diff --name-only HEAD^..HEAD actual
+ test_cmp expect_none
+ test_must_fail git diff -Obogus_file --name-only HEAD^..HEAD
+'
+
+test_expect_success POSIXPERM,SANITY 'unreadable orderfile' '
+ unreadable_file
+ chmod -r unreadable_file
+ test_must_fail git diff -Ounreadable_file --name-only HEAD^..HEAD
+'
+
+test_expect_success
option ($i) '
git diff -Oorder_file_$i --name-only HEAD^..HEAD actual
test_cmp expect_$i actual
'
This funny indentation in the previous step needs to be fixed, and
the added block below should match.
Even though this results in oddly-indented --verbose output?
+ rm -f
On Tue, Dec 17, 2013 at 5:09 PM, Junio C Hamano gits...@pobox.com wrote:
My point was that I did not see much value in reading the orderfile
data from anything but a file. At that point, you are not testing
the diff -O orderfile option, but if strbuf_readline() reads from
a non-regular file.
*.c
- *
EOF
cat expect_none -\EOF
@@ -77,27 +75,30 @@ test_expect_success 'orderfile is a directory' '
for i in 1 2
do
test_expect_success orderfile using option ($i) '
- git diff -Oorder_file_$i --name-only HEAD^..HEAD actual
- test_cmp expect_$i
-f bogus_file
+ test_must_fail git diff -Obogus_file --name-only HEAD^..HEAD
+'
+
+test_expect_success 'unreadable orderfile' '
+ touch unreadable_file
+ chmod -r unreadable_file
+ test_must_fail git diff -Ounreadable_file --name-only HEAD^..HEAD
+ test_must_fail git diff -Obogus_file --name-only HEAD^..HEAD
+'
+
+test_expect_success 'unreadable orderfile' '
+ touch unreadable_file
+ chmod -r unreadable_file
+ test_must_fail git diff -Ounreadable_file --name-only HEAD^..HEAD
+'
+
+test_expect_success 'orderfile
+ d.txt
+ a.h
+ b.c
+ EOF
+
+ cat expect_2 -\EOF
+ c/Makefile
+ a.h
+ b.c
+ d.txt
+ EOF
+
+ true# end chain of
+'
+
+test_expect_success no order (=tree object order) '
+ git diff --name-only HEAD^..HEAD actual
Samuel Bronson naes...@gmail.com writes:
for i in 1 2
do
test_expect_success orderfile using option ($i) '
git diff -Oorder_file_$i --name-only HEAD^..HEAD actual
test_cmp expect_$i actual
'
This funny indentation in the previous step needs to be fixed, and
the added
On Mon, Dec 16, 2013 at 4:09 PM, Junio C Hamano gits...@pobox.com wrote:
Samuel Bronson naes...@gmail.com writes:
+test_expect_success 'unreadable orderfile' '
+ touch unreadable_file
+ chmod -r unreadable_file
- this test probably needs restricted to people with sane
On Mon, Dec 16, 2013 at 4:32 PM, Junio C Hamano gits...@pobox.com wrote:
Samuel Bronson naes...@gmail.com writes:
for i in 1 2
do
test_expect_success orderfile using option ($i) '
git diff -Oorder_file_$i --name-only HEAD^..HEAD actual
test_cmp expect_$i actual
--- a/t/t4056-diff-order.sh
+++ b/t/t4056-diff-order.sh
@@ -61,12 +61,35 @@ test_expect_success no order (=tree object order) '
test_cmp expect_none actual
'
+test_expect_success 'missing orderfile' '
+ rm -f bogus_file
+ test_must_fail git diff -Obogus_file --name-only HEAD
+ d.txt
+ a.h
+ b.c
+ EOF
+
+ cat expect_2 -\EOF
+ c/Makefile
+ a.h
+ b.c
+ d.txt
+ EOF
+
+ true# end chain of
+'
+
+test_expect_success no order (=tree object order) '
+ git diff --name-only HEAD^..HEAD actual
:
die(unknown modifier %s for %s % (modifier, path))
-diffcmd = git format-patch -k --stdout \%s^\..\%s\ % (id, id)
+diffcmd = git diff-tree -p \%s\ % (id)
patchcmd = diffcmd + | git apply
tryPatchCmd = patchcmd + --check
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
\ % (id, id)
+diffcmd = git diff-tree -p \%s\ % (id)
patchcmd = diffcmd + | git apply
tryPatchCmd = patchcmd + --check -
applyPatchCmd = patchcmd + --check --apply -
))
-diffcmd = git format-patch -k --stdout \%s^\..\%s\ % (id, id)
+diffcmd = git diff-tree -p \%s\ % (id)
patchcmd = diffcmd + | git apply
tryPatchCmd = patchcmd + --check -
applyPatchCmd = patchcmd + --check --apply -
I do not do p4 myself, but from
I just commented out few lines, git diff is fine :
@@ -144,10 +145,10 @@ StartUML || exit 2
SHARES=
if [[ $VICTIMS -eq 1 ]]; then
-# SHARES=/tmp
-# SHARES=$SHARES /mnt/hostfs
-# SHARES=$SHARES /mnt/nfsv2
-# SHARES=$SHARES /mnt/nfsv3
+ SHARES=/tmp
+ SHARES
$ cat a
111
fdsf
333
$ cat b
111
222
333
$ git diff a b # OK
diff --git a/a b/b
index 768560b..641d574 100644
--- a/a
+++ b/b
@@ -1,3 +1,3 @@
111
-fdsf
+222
333
$ git diff (cat a) (cat b) # ERROR: no result print out
diff --git a/dev/fd/63 b/dev/fd/62
index
On Tue, Nov 05, 2013 at 08:03:28AM +0800, chunguang qu wrote:
$ cat a
111
fdsf
333
$ cat b
111
222
333
$ git diff a b # OK
diff --git a/a b/b
index 768560b..641d574 100644
--- a/a
+++ b/b
@@ -1,3 +1,3 @@
111
-fdsf
+222
333
$ git diff (cat a) (cat b
diffcore_count_changes() can return -1 when src_copied is greater than
delta_limit, without counting all the src_copied.
By that, performance of diff -M/-C can be improved.
Signed-off-by: Tsuneo Yoshioka yoshiokatsu...@gmail.com
---
diffcore-delta.c | 11 ---
diffcore-rename.c | 2 +-
.
words, the differences are what you _could_ tell Git to
further add to the index but you still haven't. You can
stage these changes by using linkgit:git-add[1].
-+
-If exactly two paths are given and at least one points outside
-the current repository, 'git diff' will compare the two
of the command,
... My preference is ... But that's not how git-diff works.
So given the constraints, I think this is the best we can do. As nobody
seems to be helping to polish the text, here is my attempt, on top
of your patch.
Documentation/git-diff.txt | 14 +-
1 file changed, 9 insertions
From: Junio C Hamano gits...@pobox.com
I suspect that it may be a good idea to split the section altogether
to reduce confusion like what triggered this thread, e.g.
'git diff' [--options] [--] [path...]::
This form is to view the changes you made relative
Clarify documentation for git-diff: State that when not inside a
repository, --no-index is implied (and thus two arguments are
mandatory).
Clarify error message from diff-no-index to inform user that CWD is
not inside a repository and thus two arguments are mandatory.
Signed-off-by: Dale Worley
wor...@alum.mit.edu (Dale R. Worley) writes:
The error message has been updated from [PATCH]. git diff outside a
repository now produces:
Not a git repository
To compare two paths outside a working tree:
usage: git diff [--no-index] path path
This should inform the user
Clarify documentation for git-diff: State that when not inside a
repository, --no-index is implied (and thus two arguments are
mandatory).
Clarify error message from diff-no-index to inform user that CWD is
not inside a repository and thus two arguments are mandatory.
Signed-off-by: Dale Worley
wor...@alum.mit.edu (Dale R. Worley) writes:
Unfortunately, the error message presupposes that the decision to
execute diff-no-index reflects the user's intention, thus leaving me
confused, as the error message is only:
usage: git diff [--no-index] path path
and does not cover the case I
Hi,
Please document git blame --no-follow and git diff --no-follow
Regards,
ch3cooli
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
to
apply it to origin/sb/misc-fixes, whereas the second patch will make
git diff complain about the -q option, so I'd assume it would wait for the
next major release?
Before:
touch actual_file
git diff -q actual_file no_file
error: Could not access 'no_file'
Hmm, do you really
On Wed, Jul 17, 2013 at 10:04 AM, Junio C Hamano gits...@pobox.com wrote:
If we wanted to make -q follow the spirit of its original addition
to show-diff again, we could internally add a diff-filter when the
-q option is parsed.
Having said all that, I do not mean to advocate to retain -q.
.
echo $?
1
Ok here we go (using current origin/master 9c3c367):
cd $(mktemp -d)
echo test actual_file
git diff actual_file no_file
# error: Could not access 'no_file'
echo $?
1
## I get the same message as well, if I'm using
v1.5.6-rc1~41^2~2, the option parsing for diff --no-index
and git diff-files shared code. In git diff-files, -q means
to be silent about removed files. In git diff --no-index, in
various versions it has been an error, an infinite loop, or a no-op.
Simplify the code
Torsten Bögershausen tbo...@web.de writes:
+++ b/diff.c
@@ -2647,6 +2647,10 @@ static int diff_populate_gitlink(struct diff_filespec
*s, int size_only)
int diff_populate_filespec(struct diff_filespec *s, int size_only)
{
int err = 0;
+enum safe_crlf crlf_warn = (safe_crlf !=
Hi,
Le 24.06.2013 18:55, Junio C Hamano a écrit :
Yann Droneaud ydrone...@opteya.com writes:
- Why git diff does not always report the CRLF/LF mismatch ?
Most likely because you are telling safecrlf not to error out but
just warn, and then you are not fixing the cause of the warning? So
+++ b/diff.c
@@ -2647,6 +2647,10 @@ static int diff_populate_gitlink(struct diff_filespec
*s, int size_only)
int diff_populate_filespec(struct diff_filespec *s, int size_only)
{
int err = 0;
+ enum safe_crlf crlf_warn = (safe_crlf != SAFE_CRLF_FAIL
+
Hi,
Le 21.06.2013 23:57, Junio C Hamano a écrit :
Junio C Hamano gits...@pobox.com writes:
The helper may want to learn a way to be told to demote that error
to a warning.
Perhaps something like this?
Thanks for the patch.
I run my test again, eg. run git diff after a rebase failure
Hi,
I'm still trying to use .gitattributes text flag with CRLF line ending
files
under Linux.
I'm surprised about the interaction between the index and the working
directory,
more specificaly about the interaction between git diff and git status:
$ git init
Initialized empty Git
Le 24.06.2013 18:37, Yann Droneaud a écrit :
I'm still trying to use .gitattributes text flag with CRLF line
ending files
under Linux.
I'm surprised about the interaction between the index and the working
directory,
more specificaly about the interaction between git diff and git status
Yann Droneaud ydrone...@opteya.com writes:
- Why git diff does not always report the CRLF/LF mismatch ?
Most likely because you are telling safecrlf not to error out but
just warn, and then you are not fixing the cause of the warning? So
diff would say Ok, you must know what you are doing, so
Le 24.06.2013 18:37, Yann Droneaud a écrit :
I'm still trying to use .gitattributes text flag with CRLF line
ending files
under Linux.
I'm surprised about the interaction between the index and the working
directory,
more specificaly about the interaction between git diff and git status
Yann Droneaud ydrone...@opteya.com writes:
Hi,
Le 21.06.2013 23:57, Junio C Hamano a écrit :
Junio C Hamano gits...@pobox.com writes:
The helper may want to learn a way to be told to demote that error
to a warning.
Perhaps something like this?
Thanks for the patch.
Care to turn it
/t0020-crlf.sh
+++ b/t/t0020-crlf.sh
@@ -81,6 +81,14 @@ test_expect_success 'safecrlf: print warning only once' '
test $(git add doublewarn 21 | grep CRLF will be replaced by LF |
wc -l) = 1
'
+
+test_expect_success 'safecrlf: git diff demotes safecrlf=true to warn' '
+ git config
diff is
returning
fatal: CRLF would be replaced by LF without returning any kind of
diff.
This make me wonder if its the correct behavor for git diff to (only)
fail:
It should be fatal for git add / git commit ( / git cherry-pick / ...
?),
but non fatal for git diff.
According
Yann Droneaud ydrone...@opteya.com writes:
While testing the behavor of Git regarding CRLF handling,
when core.safecrlf is set to true, I've found that git diff is
returning
fatal: CRLF would be replaced by LF without returning any kind of
diff.
This make me wonder if its the correct
Junio C Hamano gits...@pobox.com writes:
The helper may want to learn a way to be told to demote that error
to a warning.
Perhaps something like this?
diff.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/diff.c b/diff.c
index f0b3e7c..9b4f3ac 100644
--- a/diff.c
The section describing git diff blob blob had been placed in a
position that disrupted the statement This is synonymous to the
previous form.
Reorder to place this form after all the commit-using forms, and the
note applying to them. Also mention this form in the initial description
paragraph
Thanks, makes sense. Will queue.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jun 10, 2013 at 8:44 AM, Célestin Matte
celestin.ma...@ensimag.fr wrote:
Since nobody answered you (publicly at least), I will try doing it myself:
I think the best thing to do if you want a feature to be added is to
come with a patch and request for comments on it. Then, people will
On Thu, Jun 6, 2013 at 6:17 PM, Junio C Hamano gits...@pobox.com wrote:
Célestin Matte celestin.ma...@ensimag.fr writes:
But for a two-endpoint diff Porcelain (not the plumbing diff-files,
diff-index and diff-tree), I do not think it is particularly a bad
idea to add such a typo-detection
Hello All,
If I did 'git diff HEAD^..HEAD -- file' should git not report some
kind of warning if it could not match the file? For example, if 'file'
were infact 'dir/file' and 'file' were unique, would it not be a good
idea to report that in the present working directory 'file' were not
found
Le 06/06/2013 23:26, Sarma Tangirala a écrit :
Hello All,
If I did 'git diff HEAD^..HEAD -- file' should git not report some
kind of warning if it could not match the file? For example, if 'file'
were infact 'dir/file' and 'file' were unique, would it not be a good
idea to report
Célestin Matte celestin.ma...@ensimag.fr writes:
Le 06/06/2013 23:26, Sarma Tangirala a écrit :
Hello All,
If I did 'git diff HEAD^..HEAD -- file' should git not report some
kind of warning if it could not match the file? For example, if 'file'
were infact 'dir/file' and 'file' were unique
On 2012-11-07 22:13, Jeff King wrote:
On Wed, Nov 07, 2012 at 10:10:59PM +0100, Peter Oberndorfer wrote:
For me the key to reproduce the problem was to have 2 commits.
Adding the file in the root commit it did not work. [1]
You probably would need to pass --root for it to do the diff of the
On Mon, Jun 03, 2013 at 07:25:06PM +0200, Peter Oberndorfer wrote:
Thanks for the report. I'd still like to pursue using a regex library
that does not require NUL-termination, but I've been distracted by other
things. I'm going to hold back my copy-to-a-NUL-buffer patch for now and
see if
Junio C Hamano wrote:
--- a/Documentation/git-diff-index.txt
+++ b/Documentation/git-diff-index.txt
@@ -3,7 +3,7 @@ git-diff-index(1)
NAME
-git-diff-index - Compares content and mode of blobs between the index and
repository
+git-diff-index - Compare a tree and the working tree
301 - 400 of 503 matches
Mail list logo
