Jonathan Nieder jrnie...@gmail.com writes:
Thanks and hope that helps,
Jonathan
Thanks, the result reads much better, I think.
Albert?
diff --git i/Documentation/git-diff-index.txt
w/Documentation/git-diff-index.txt
index 58308e15..a86cf62e 100644
--- i/Documentation/git-diff-index.txt
Albert Netymk albertnet...@gmail.com writes:
On Sun, May 19, 2013 at 9:46 AM, Junio C Hamano gits...@pobox.com wrote:
Albert Netymk albertnet...@gmail.com writes:
Hello,
The man page of git-diff-index:
http://git-scm.com/docs/git-diff-index
states that
`git-diff-index - Compares content
On Mon, May 20, 2013 at 1:01 AM, Junio C Hamano gits...@pobox.com wrote:
Subject: [PATCH] Documentation/diff-index: mention two modes of operation
diff-index can be used to compare a tree with the tracked working
tree files (when used without the --index option), or with the index
(when used
Albert Netymk albertnet...@gmail.com writes:
Hello,
The man page of git-diff-index:
http://git-scm.com/docs/git-diff-index
states that
`git-diff-index - Compares content and mode of blobs between the index
and repository`.
However, in fact this command compares between files on disk
Hello,
The man page of git-diff-index:
http://git-scm.com/docs/git-diff-index
states that
`git-diff-index - Compares content and mode of blobs between the index
and repository`.
However, in fact this command compares between files on disk and
repository by default. It's explained clearly in here
The output of git-diff is different from my expectation.
It may skip some lines of context.
For the case of the diff result attached here, a blank line and a line
with a leading slash is skipped.
Please check out the attached files for details.
Thanks.
ab.patch
Description: Binary data
int
On Wed, May 15, 2013 at 8:23 AM, eric liou accw...@gmail.com wrote:
The output of git-diff is different from my expectation.
It may skip some lines of context.
git-diff is using a default of 3 lines of context above and below the changes.
In your example, there is only two lines of context
On Wed, May 15, 2013 at 8:52 AM, eric liou accw...@gmail.com wrote:
Thank you for the quick reply.
But this line is not correct: @@ -4,5 +4,6 @@ int a = 1;
Oh OK, I see.
Git tries to name the function where the changes take place. This is
purely informative.
In your example, you don't have any
Antoine Pelisse apeli...@gmail.com writes:
On Wed, May 15, 2013 at 8:52 AM, eric liou accw...@gmail.com wrote:
Thank you for the quick reply.
But this line is not correct: @@ -4,5 +4,6 @@ int a = 1;
Antoine's answer is correct. In addition, I'd say that you may want to
enable color in the
On Wed, May 15, 2013 at 11:34:41AM +0200, Matthieu Moy wrote:
Antoine's answer is correct. In addition, I'd say that you may want to
enable color in the output to make it clearer (the @@ ... @@ part would
be colored, but not the function name):
git config --global color.ui auto
I wonder
John Keeping j...@keeping.me.uk writes:
I wonder if that should be the default. I've advised a lot of people to
turn it on and it seems to me that a user is much more likely to go
looking for a turn color off option than realise that color is an
option at all.
I'd love to see this by
On Wed, May 15, 2013 at 5:03 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
John Keeping j...@keeping.me.uk writes:
I wonder if that should be the default. I've advised a lot of people to
turn it on and it seems to me that a user is much more likely to go
looking for a turn color off
On Wed, May 15, 2013 at 10:50:25AM +0100, John Keeping wrote:
On Wed, May 15, 2013 at 11:34:41AM +0200, Matthieu Moy wrote:
Antoine's answer is correct. In addition, I'd say that you may want to
enable color in the output to make it clearer (the @@ ... @@ part would
be colored, but not the
Hi folks,
while trying to parse git diff-tree output, I found out that in some
cases it appears to generate an incorrect diff (AFAICT). I orginally
found this in a 5-way merge commit in the Linux kernel, but managed to
reduce this to something a lot more managable (an ordinary 2-way merge
on a 6
Hi folks,
$ git diff-tree -p -c HEAD
d945a51b6ca22e6e8e550c53980d026f11b05158
diff --combined file
index 3404f54,0eab113..e8c8c18
--- a/file
+++ b/file
@@@ -1,7 -1,5 +1,6 @@@
+LEFT
BASE2
BASE3
BASE4
- BASE5
+ BASE5MODIFIED
BASE6
I found the spot in the code where
Matthijs Kooijman matth...@stdin.nl writes:
$ git diff-tree -p -c HEAD
d945a51b6ca22e6e8e550c53980d026f11b05158
diff --combined file
index 3404f54,0eab113..e8c8c18
--- a/file
+++ b/file
@@@ -1,7 -1,5 +1,6 @@@
+LEFT
BASE2
BASE3
BASE4
- BASE5
+ BASE5MODIFIED
BASE6
Here
Hi Junio,
I think the coalescing of two adjacent hunks into one is painting
leading lines interesting to show context but not worth showing
deletion before it incorrectly.
Yup, that seems to be the case.
Does this patch fix the issue?
Yes, it fixes the issue. However, I think that this
Matthijs Kooijman matth...@stdin.nl writes:
Hi Junio,
I think the coalescing of two adjacent hunks into one is painting
leading lines interesting to show context but not worth showing
deletion before it incorrectly.
Yup, that seems to be the case.
Does this patch fix the issue?
Yes, it
Hi Junio,
Could you explain why you think it hides the real problem, and what
kind of future enhancement may break it?
I think the differences is mostly in the locality of the fix. In my
proposed patch, the no_pre_delete flag is never set on an interesting
line because it is checked in the line
Matthijs Kooijman matth...@stdin.nl writes:
Could you explain why you think it hides the real problem, and what
kind of future enhancement may break it?
I think the differences is mostly in the locality of the fix. In my
proposed patch, the no_pre_delete flag is never set on an interesting
I'm seeing a strange problem where git diff --quiet sometimes returns an
exit code of zero even though the tree is dirty and other invocations of
git diff --quiet in the same directory return an exit code of 1. I'm
using git v1.8.2 from Debian unstable but I've also seen the problem when
running
was that 'git diff --stat' would only summerize per-binary-file
size changes and 'git diff --shortstat' did skip the binary files entirely.
To solve this problem, I wrote a script (gitdiffbinstat) which
basically runs 'git diff --stat' and summerizes the output.
The script can be found here:
https
smaller the new branch
was in comparison to master.
Problem was that 'git diff --stat' would only summerize
per-binary-file size changes and 'git diff --shortstat' did skip the
binary files entirely.
Have you tried --summary? Combined with --stat (or --shortstat) I
wonder if it would get you
was in comparison to master.
Problem was that 'git diff --stat' would only summerize
per-binary-file size changes and 'git diff --shortstat' did skip the
binary files entirely.
Have you tried --summary? Combined with --stat (or --shortstat) I
wonder if it would get you closer to what you want.
diff
Dear Sir,
In git 1.8.1, git-diff supports diff.context config.
However, git-diff-tree does not support this.
Could you also add this to git-diff-tree?
Regards,
ch3cooli
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
乙酸鋰 ch3co...@gmail.com writes:
In git 1.8.1, git-diff supports diff.context config.
However, git-diff-tree does not support this.
Could you also add this to git-diff-tree?
That's more or less deliberate, isn't it?
Cosmetic details of the output from plumbing commands should not be
affected
Under the --color=when option, it says:
Show colored diff. The value must be always (the default for when),
never, or auto. The default value is never.
That seems to imply that the default is both always and never. If I'm
right, I suggest removing the parenthesis, and putting the correct
default
Reuben Thomas r...@sc3d.org writes:
Under the --color=when option, it says:
Show colored diff. The value must be always (the default for when),
never, or auto. The default value is never.
I think it wants to say this:
You can say diff --color without saying when. That is the
same
diff.
-The value must be `always` (the default for `when`), `never`, or `auto`.
-The default value is `never`.
+Show colored diff (off by default).
+The value must be `always`, `never`, or `auto`.
+`--color` is the same as `--color=always`.
ifdef::git-diff[]
It can be changed
: Autocomplete --minimal and --histogram for
git-diff
config: Introduce diff.algorithm variable
diff: Introduce --diff-algorithm command line option
Documentation/diff-config.txt | 18 ++
Documentation/diff-options.txt | 21 +
contrib/completion
Even though --patience was already there, we missed --minimal and
--histogram for some reason.
Signed-off-by: Michal Privoznik mpriv...@redhat.com
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
Even though --patience was already there, we missed --minimal and
--histogram for some reason.
Signed-off-by: Michal Privoznik mpriv...@redhat.com
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
It's been a while I was trying to get this in. Recently, I realized how
important this is.
Please keep me CC'ed as I am not subscribed to the list.
diff to v1:
-Junio's suggestions worked in
Michal Privoznik (3):
git-completion.bash: Autocomplete --minimal and --histogram for
git-diff
Even though --patience was already there, we missed --minimal and
--histogram for some reason.
Signed-off-by: Michal Privoznik mpriv...@redhat.com
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
It's been a while I was trying to get this in. Recently, I realized how
important this is.
Please keep me CC'ed as I am not subscribed to the list.
Michal Privoznik (3):
git-completion.bash: Autocomplete --minimal and --histogram for
git-diff
config: Introduce diff.algorithm variable
expected:
$ git diff --ignore-space-at-eol test.txt
$ git diff --ignore-space-at-eol --stat test.txt
test.txt | 0
1 file changed, 0 insertions(+), 0 deletions(-)
$ git diff --ignore-space-at-eol --name-status test.txt
M test.txt
The idea is that even though diff doesn't show any differences
$ git diff --ignore-space-at-eol test.txt
$ git diff --ignore-space-at-eol --stat test.txt
test.txt | 0
1 file changed, 0 insertions(+), 0 deletions(-)
$ git diff --ignore-space-at-eol --name-status test.txt
M test.txt
The idea is that even though diff doesn't show any differences, stat
with no changes
(starting by 0 0).
On Fri, Dec 28, 2012 at 8:59 PM, John Moon johnmoo...@hotmail.com wrote:
$ git diff --ignore-space-at-eol test.txt
$ git diff --ignore-space-at-eol --stat test.txt
test.txt | 0
1 file changed, 0 insertions(+), 0 deletions(-)
$ git diff --ignore-space
) 5c4ce92] .
1 file changed, 1 insertion(+)
create mode 100644 test.txt
$ printf hello test.txt
$ git diff --ignore-space-at-eol test.txt
$ git diff --stat --ignore-space-at-eol test.txt
0 files changed
$ git diff --name-status --ignore-space-at-eol test.txt
M test.txt
Thanks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
Documentation seems to suggest this is supported, but it is not true:
$ git diff HEAD:git.c HEAD~100:git.c -- git.c
usage: git diff [options] [commit [commit]] [--] [path...]
unless I'm missing something.
Manlio
-BEGIN PGP SIGNATURE
Manlio Perillo manlio.peri...@gmail.com writes:
Documentation seems to suggest this is supported, but it is not true:
$ git diff HEAD:git.c HEAD~100:git.c -- git.c
usage: git diff [options] [commit [commit]] [--] [path...]
unless I'm missing something.
Neither HEAD:git.c nor HEAD~100
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 18/12/2012 19:11, Junio C Hamano ha scritto:
Manlio Perillo manlio.peri...@gmail.com writes:
Documentation seems to suggest this is supported, but it is not true:
$ git diff HEAD:git.c HEAD~100:git.c -- git.c
usage: git diff [options
Manlio Perillo manlio.peri...@gmail.com writes:
I'm not sure the man page is wrong and should be changed:
-- usage: git diff [options] [commit [commit]] [--] [path...]
++ usage: git diff [options] [commit [commit]]
Comparison of two blob objects works entirely in different way
Nguyen Thai Ngoc Duy pclo...@gmail.com writes:
On Sat, Oct 27, 2012 at 7:33 PM, Junio C Hamano gits...@pobox.com wrote:
Nguyen Thai Ngoc Duy pclo...@gmail.com wrote:
Notice the --cc in the first line, which is combined diff. Usually
combined-diff is between two points and one parent. Though
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
initial commit.
The patch below
Jeff King wrote:
Thinking on it more, my patch, hacky thought it seems, may not be the
worst solution. Here are the options that I see:
1. Use a regex library that does not require NUL termination. If we
are bound by the regular regexec interface, this is not feasible.
But the
for something like git
diff HEAD^.
I really wish there were an alternate regexec interface we could use
that took a pointer/size pair. Bleh.
Thinking on it more, my patch, hacky thought it seems, may not be the
worst solution. Here are the options that I see:
1. Use a regex library
be because we are literally
diffing
the working tree. -G was meant to be used to limit log
traversal,
but it also works to reduce the diff output for something like
git
diff HEAD^.
I really wish there were an alternate regexec interface we could use
that took a pointer/size pair
On Tue, Oct 30, 2012 at 09:46:01PM +0900, Junio C Hamano wrote:
(1) sounds attractive for more than one reason. In addition to
avoidance of this issue, it would bring bug-to-bug compatibility
across platforms.
Yeah. I mentioned breaking the build for people who would now need to
turn on
Am 28.10.2012 01:02, schrieb Jens Lehmann:
Am 26.10.2012 22:43, schrieb Francis Moreau:
On Fri, Oct 26, 2012 at 10:05 PM, Jens Lehmann jens.lehm...@web.de wrote:
[...]
That is weird, git diff --submodule should show that too. Is there
anything unusual about your setup? (The only explanation
:0x3000 returned:
0xb771e000
1 file changed, 1 insertion(+)
create mode 100644 asdf.txt
kumbayo@soybean:~/src/git_mmap_crash2$ valgrind git diff-tree -Ganything HEAD
==8388== Memcheck, a memory error detector
==8388== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==8388== Using
On Mon, Oct 29, 2012 at 09:19:48PM +0100, Peter Oberndorfer wrote:
I could reproduce with my 0x3000 bytes file on linux. The buffer is not
read with a trailing null byte it is mapped by mmap in
diff_populate_filespec...
So i think we will not get away with expecting a trailing null :-/
of the reason a filespec
might be mmap'd. It might also be because we are literally diffing
the working tree. -G was meant to be used to limit log traversal,
but it also works to reduce the diff output for something like git
diff HEAD^.
I really wish there were an alternate
On Sun, Oct 28, 2012 at 1:02 AM, Jens Lehmann jens.lehm...@web.de wrote:
Am 26.10.2012 22:43, schrieb Francis Moreau:
On Fri, Oct 26, 2012 at 10:05 PM, Jens Lehmann jens.lehm...@web.de wrote:
[...]
That is weird, git diff --submodule should show that too. Is there
anything unusual about your
On Sat, Oct 27, 2012 at 08:37:24PM +0200, Peter Oberndorfer wrote:
It seems git diff-tree -Ganything tree crashes[1] with a null
pointer dereference
when run on a commit that adds a file (pdf) with a textconv filter.
It can be reproduced with vanilla git by having a commit on top that
adds
On 2012-10-28 13:01, Jeff King wrote:
On Sat, Oct 27, 2012 at 08:37:24PM +0200, Peter Oberndorfer wrote:
It seems git diff-tree -Ganything tree crashes[1] with a null
pointer dereference
when run on a commit that adds a file (pdf) with a textconv filter.
It can be reproduced with vanilla
to fix.
Is there any use case where HEAD...HEAD (or ... alone) is actually useful?
I have re-read the git-diff man page and I don't think it explains
git diff foo ... bar syntax (from a user's point of view, not a git
guru's). We could improve the documentation if git diff foo ... bar
is useful
Hi,
It seems git diff-tree -Ganything tree crashes[1] with a null
pointer dereference
when run on a commit that adds a file (pdf) with a textconv filter.
It can be reproduced with vanilla git by having a commit on top that
adds a file with a textconv filter and executing git diff-tree
-Ganything
Am 26.10.2012 22:43, schrieb Francis Moreau:
On Fri, Oct 26, 2012 at 10:05 PM, Jens Lehmann jens.lehm...@web.de wrote:
[...]
That is weird, git diff --submodule should show that too. Is there
anything unusual about your setup? (The only explanation I can come
up with after checking the code
Am 26.10.2012 16:07, schrieb Francis Moreau:
I'm trying to use the --submodule switch with git-diff but doesnt
understand the following behaviour:
$ git diff 2c9a257718d1803de720f95766ff256d33accad5 HEAD
diff --git a/configs b/configs
index 16c6a89..ce12289 16
--- a/configs
+++ b
Hi,
Thanks for answering
On Fri, Oct 26, 2012 at 9:08 PM, Jens Lehmann jens.lehm...@web.de wrote:
Am 26.10.2012 16:07, schrieb Francis Moreau:
I'm trying to use the --submodule switch with git-diff but doesnt
understand the following behaviour:
$ git diff
Am 26.10.2012 21:54, schrieb Francis Moreau:
On Fri, Oct 26, 2012 at 9:08 PM, Jens Lehmann jens.lehm...@web.de wrote:
Am 26.10.2012 16:07, schrieb Francis Moreau:
I'm trying to use the --submodule switch with git-diff but doesnt
understand the following behaviour:
$ git diff
On Fri, Oct 26, 2012 at 10:05 PM, Jens Lehmann jens.lehm...@web.de wrote:
[...]
That is weird, git diff --submodule should show that too. Is there
anything unusual about your setup? (The only explanation I can come
up with after checking the code is that your submodule has neither a
.git
I came across this odd question on stackoverflow:
http://stackoverflow.com/q/13092854/1507392
If git diff is run with ... as a separate argument between two
commit-ish arguments causes it to produce strange output. The
differences seem to be the same as if ... was left out
On Sat, Oct 27, 2012 at 4:26 AM, Aaron Schrab aa...@schrab.com wrote:
I came across this odd question on stackoverflow:
http://stackoverflow.com/q/13092854/1507392
If git diff is run with ... as a separate argument between two commit-ish
arguments causes it to produce strange output
I'll see if I can come up with a patch that cater for both use-cases.
I see that I forgot to Cc you; please see the patch series starting
with the Subject [RFC PATCH 0/2] Localize log output, which I posted
here yesterday.
--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from
With merge conflicts in the work-tree, diff's exit-code seems inconsistent. I
thought --quiet implied --exit-code
/others/foo$ git diff --quiet
/others/foo$ echo $?
1
/others/foo$ git diff --exit-code
diff --cc foo.txt
index f3dc283,bea67fd..000
--- a/foo.txt
+++ b/foo.txt
/others/foo
Nguyen Thai Ngoc Duy:
It's the result of this discussion [1]. I don't remember exactly the
open issues. But I think it involves drawing a line between team
language vs local language, whether team language can be anything
other than English, the maintenance cost for supporting it
Like I said,
Hi!
The output of git format-patch and git diff --stat no longer
becomes localized when using 1.8.0.rc2, compared to 1.7.12
Running both versions of git format-patch -1 from the same
repository, with the same settings otherwise, has 1.7.12 output the
diffstat summary in Swedish, while 1.8.0
On Wed, Oct 17, 2012 at 5:53 PM, Peter Krefting pe...@softwolves.pp.se wrote:
Hi!
The output of git format-patch and git diff --stat no longer becomes
localized when using 1.8.0.rc2, compared to 1.7.12
It's the result of this discussion [1]. I don't remember exactly the
open issues. But I
The behavior of git diff --stat is rather odd for files that have
zero lines of changes: it will discount them entirely unless they were
renames.
Which means that the stat output will simply not show files that only
had other changes: they were created or deleted, or their mode was
changed.
Now
Linus Torvalds torva...@linux-foundation.org writes:
So if you did
chmod +x Makefile
git diff --stat
before, it would show empty ( 0 files changed), with this it shows
Makefile | 0
1 file changed, 0 insertions(+), 0 deletions(-)
which I think is a more correct diffstat
On Wed, Oct 17, 2012 at 11:28 AM, Junio C Hamano gits...@pobox.com wrote:
I think listing a file whose content remain unchanged with 0 as the
number of lines affected makes sense, and it will mesh well with
Duy's
http://thread.gmane.org/gmane.comp.version-control.git/207749
I first
git diff commit..commit
and
git diff commit commit
both succeed
however
git diff commit:path..commit:path
fails while
git diff commit:path commit:path
succeeds
OS X 10.7.5
git version 1.7.9.1
Reproduced by another user:
http://stackoverflow.com/questions/12805004/git-cherry-pick-creates-blobs
Arthur Etchells adetche...@gmail.com writes:
git diff commit:path..commit:path
commit:path represents a tree or blob, but .. requires commits as
its end points.
(You can dereference a commit to get a tree or blob, but not the other
way round.)
Andreas.
--
Andreas Schwab, sch...@linux
Arthur Etchells adetche...@gmail.com writes:
git diff commit..commit
and
git diff commit commit
both succeed
however
git diff commit:path..commit:path
fails while
git diff commit:path commit:path
succeeds
...
It seems logical to support the '..' syntax in both for consistency.
git
Hi,
is there a way to tell git diff about lines that are uninteresting?
I mean lines which do not contain a lot of information and
appear several times in pre and post image.
For example whitespace or language dependent stuff like.
{
}
END_IF;
END_FOR;
end sub
I have seen diffs that containing
is a
virus scanner.
git diff-* plumbing commands are meant to be used after running
git update-index --refresh once in the program and when the caller
of these commands (in your case, gitk) knows that any change in the
information returned by lstat(2) on the paths in the working tree
files
not quite figured out the exact set of
circumstances yet)
Figure that circumstances out. That is the key to the issue.
Something in your workflow is futzing with the inode data of the
files in your working tree behind your back. It sometimes is a
virus scanner.
git diff-* plumbing commands
) git diff-files shows that every file in my repo
is modified, when I expect none to be.
Diff-files only looks at the cached sha1 in the index. It will not
re-read the file to update its index entry if its stat information
appears out of date. So what is happening is that another program[1
.
The commit data from the renaming operation (last commit in the script-
generated history) is inexactly rendered by the command
git diff-tree -r -C master
The logical result is correctly produced by the more restricted command
git diff-tree -r -M master
IMO for this particular last
Am 20.09.2012 00:31, schrieb Junio C Hamano:
Junio C Hamano gits...@pobox.com writes:
I also suspect that you do not have to change git diff at all to
show the patch recursively by using the attribute mechanism (look in
Documentation/gitattributes.text for a string GIT_EXTERNAL_DIFF
Jens Lehmann jens.lehm...@web.de writes:
That's pretty cool! Even though diff options like --stat and --name-only
still won't take into account what happened inside the submodule this
approach makes it possible to see the diff recursively. Wouldn't it make
sense add this script to contrib
Hello
A colleague of mine discovered an inconsistency in the functioning of
git diff-tree -r -C
in specific conditions. As tenuous as these conditions might seem (once you
run the script in attachment and analyse its output), please rest assured that
it comes from a real-life case.
Running
Am 18.09.2012 05:12, schrieb Kenny Simpson:
Is there any nice way to get a diff and/or diffstat of both a project and
its submodules between two revisions of the main project?
Something like 'git diff --stat tag_a tag_b' but also including the diffstat
on the submodule from the revision
Jens Lehmann jens.lehm...@web.de writes:
Am 18.09.2012 05:12, schrieb Kenny Simpson:
Is there any nice way to get a diff and/or diffstat of both a project and
its submodules between two revisions of the main project?
Something like 'git diff --stat tag_a tag_b' but also including
Hello,
Is there any nice way to get a diff and/or diffstat of both a project and its
submodules between two revisions of the main project?
Something like 'git diff --stat tag_a tag_b' but also including the diffstat on
the submodule from the revision tied to in tag_a to the revision tied
be
illuminative. My disk's SMART data seems okay. The weird-quotient just
rose a bit.
That sounds like an issue with stat() data, and then it doesn't. cp -a
would change all the inode numbers, triggering a full refresh of the
index in 'git diff'. But I'm not sure exactly how this can lead
On Tue, Aug 14, 2012 at 10:18 AM, Thomas Rast tr...@student.ethz.ch wrote:
That sounds like an issue with stat() data, and then it doesn't. cp -a
would change all the inode numbers, triggering a full refresh of the
index in 'git diff'. But I'm not sure exactly how this can lead
/tests/common/outputs/osmond/TwoStageAmp-output.net
# note, it is important that you run diff first
git diff gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
git diff-files -p
gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
git ls-files --debug
gnetlist/tests
Thomas Rast tr...@student.ethz.ch writes:
Whatever you do next, *please* post the *exact* file contents *and*
output in a format that does not suffer any transport damage, neither to
whitespace nor to binary data (such as terminal escapes). Piping
through xxd comes to mind, perhaps by using
On Tue, Aug 14, 2012 at 11:55 AM, Thomas Rast tr...@student.ethz.ch wrote:
Fun stuff. This will be very interesting to debug. It's still
possible, though perhaps not extremely likely, that git is writing
garbage to the terminal and it just happens to work for xterm.
Whatever you do next,
copying and pasting the hunks from git add
-i into the script. However, when I used git diff to get at the
changes, to discover which line was the offending one, all additions
and deletions were exactly matched!
With strace I noticed that git add -i calls git diff-files, and that's
about as far as I
Bernd Jendrissek bernd.jendris...@gmail.com writes:
$ /usr/local/git/bin/git diff-files -p --color -- TwoStageAmp-output.net
diff --git a/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
b/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
index a5ee1e7..a9f3620 100644
Bernd Jendrissek bernd.jendris...@gmail.com writes:
$ /usr/local/git/bin/git diff-files -p --color -- TwoStageAmp-output.net
diff --git a/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
b/gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
index a5ee1e7..a9f3620 100644
On Mon, Aug 13, 2012 at 5:02 PM, Thomas Rast tr...@student.ethz.ch wrote:
Can you share this repository?
This weird behaviour doesn't even survive making a copy (cp -a) of the
whole repository, so I very much doubt making it available would be
illuminative. My disk's SMART data seems okay. The
On 8/17/05, Linus Torvalds [EMAIL PROTECTED] wrote:
NOTE! This does _not_ handle .. or . in the _middle_ of a pathspec. If
you have people who do
BTW, could this (below) be useful for something?
#include string.h
#include stdio.h
#include stdlib.h
// an analog of cd path from a directory cwd.
On 8/23/05, Alex Riesen [EMAIL PROTECTED] wrote:
On 8/17/05, Linus Torvalds [EMAIL PROTECTED] wrote:
NOTE! This does _not_ handle .. or . in the _middle_ of a pathspec. If
you have people who do
BTW, could this (below) be useful for something?
Well, a bit of explanation is certainly
On Tue, 16 Aug 2005, Linus Torvalds wrote:
This fixes up usage of .. (without an ending slash) and . (with or
without the ending slash) in the git diff family.
Btw, if it wasn't clear, with this patch you can now do
git diff .
and it will show the diffs for everything under
Hi,
Junio C Hamano:
I've considered it, but what happens if you give -z first and
then name-only?
Exactly the same thing as vice versa.
Or, even more exactly, my patch *makes* that happen. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote
401 - 500 of 503 matches
Mail list logo
