Re: [git-users] 'git diff --name-status' reports difference for zero-byte file

[Konstantin Khomoutov]

On Thu, 5 May 2016 08:28:43 -0700 (PDT)
Jack Poon  wrote:

> We are working on an add-on over git using git filters, and testing
> other tools that encapsulate Git.
> 
> For some reason, git reports that there is difference for any
> zero-byte when git filters are used.
> 
> Is this a feature or bug?  What's the suggested workaround?

I can't verify this with Git 2.1.4 on a Debian Jessie running amd64.

Here's an annotated transcript of the sample session I've just
performed.  It creates a repository, configures a filter which
merely runs `/bin/cat` both for clean and smudge actions (hence
it performs what CS PhDs would call an "identity transformation"),
sets up a .gitattributes file which applies this filter to the files
matching the "*.txt" pattern, adds two zero-length files in two
adjacent commits and verifies the diff looks as expected.

Then we force checking out of these files and try again.

% git --version
git version 2.1.4

~% cd /tmp
tmp% git init filters
Initialized empty Git repository in /tmp/filters/.git/
tmp% cd filters
filters% git config --add --local filter.foo.smudge '/bin/cat'
filters% git config --add --local filter.foo.clean '/bin/cat'
filters% cat >.gitattributes
*.txt   filter=foo
filters% touch aaa.txt
filters% stat -c %s aaa.txt 
0
filters% git add aaa.txt
filters% git commit -m 'Add aaa.txt'
[master (root-commit) bec42c4] Add aaa.txt
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 aaa.txt
filters% touch bbb.txt
filters% stat -c %s bbb.txt 
0
filters% git add bbb.txt
filters% git commit -m 'Add bbb.txt'
[master 5c30813] Add bbb.txt
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 bbb.txt
filters% git diff --name-status HEAD~1 HEAD
A   bbb.txt

Observe that the diff output looks as expected: a single file
has been added.

Now let's force checking out these files to make them pass
through the smudge filter:

filters% rm aaa.txt bbb.txt 
filters% GIT_TRACE=1 git checkout -f -- .
20:45:08.515779 git.c:349   trace: built-in: git 'checkout'
'-f' '--' '.'
20:45:08.516375 run-command.c:341   trace: run_command: '/bin/cat'
20:45:08.516607 run-command.c:192   trace: exec: '/bin/cat'
20:45:08.517432 run-command.c:341   trace: run_command: '/bin/cat'
20:45:08.517633 run-command.c:192   trace: exec: '/bin/cat'

filters%  git diff --name-status HEAD~1 HEAD
A   bbb.txt

Again, the diff looks OK.

Let's diff to the index:

filters% git diff --staged
filters% 


Hence my take on your issue is that either you have a bug in your
filter code or a bug in Git (less likely).

I'd first try to debug this a little bug further.  Use GIT_TRACE
to verify what gets called on `git add` and `git checkout`.
Use `git ls-tree` and `git cat-file` to get hold onto individual
raw blobs representing the contents of the files in the repository,
verify they are really of size zero etc.

Also make sure you don't have execution bit flips on your files:
while Git does not track permission bits, it does track execution
bit and whether the file is a symlink or not.

If all will fail, contact the main Git list, but this time, please
be sure to include all the relevant details about the system you're
observing this on -- starting with the Git version.  See [1] for
more info.

1. https://gist.github.com/tfnico/4441562

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Git diff problem with cvs $id$

[Konstantin Khomoutov]

On Mon, 6 Jul 2015 11:53:26 -0700 (PDT)
Konrád Lőrinczi klorin...@gmail.com wrote:

  Remove the it!  If you aren't using CVS those lines serve no
  purpose at all.  Even if you do use CVS the line is of dubious
  usefulness. 
 
 Unfortunately I can not remove them.
 They are in an earlier branch of a software repo, which has more
 thousand files.
 So I need a solution, where I can keep original repo, but still can
 merge with my fork, without solving conflicts in more thousand files
 because of cvs indents.

So which repo contains expanded keywords?  If yours, then do a
recursive `sed` (or whatever) invocation on all that thousand of files
and make a single commit titled Normalize CVS keywords.  Then merge
normally.  If the foreign repo contains expanded keywords, may be
`git rerere` might be of help -- it's specifically designed to remember
how you resolved past merge conflicts.

Still, I can't completely comprehend your situation: the foreign repo
supposedly should contain unexpanded keywords because to me, the only
sensible way to get a repo with expanded keywords is to have it
converted from the source one using some brain-dead tool; or may be you
have just done `git add .` on a CVS checkout?

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Git diff problem with cvs $id$

[Konrád Lőrinczi]

  Any suggestions? 

 Remove the it!  If you aren't using CVS those lines serve no purpose 
 at all.  Even if you do use CVS the line is of dubious usefulness. 


Unfortunately I can not remove them.
They are in an earlier branch of a software repo, which has more thousand 
files.
So I need a solution, where I can keep original repo, but still can merge 
with my fork, without solving conflicts in more thousand files because of 
cvs indents.


Konrad
 

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Git diff problem with cvs $id$

[Konrád Lőrinczi]

 

 So which repo contains expanded keywords?  If yours, then do a 
 recursive `sed` (or whatever) invocation on all that thousand of files 
 and make a single commit titled Normalize CVS keywords.  Then merge 
 normally.  If the foreign repo contains expanded keywords, may be 
 `git rerere` might be of help -- it's specifically designed to remember 
 how you resolved past merge conflicts. 


There is a repo with original software.
I have a repo, which contains an installed software, which has expanded cvs 
keywords.
When I started development I did not use git, yet, so all developments were 
done on the installed version, which contained expanded cvs keywords.

So maybe you are right, I should run sed through all my repo, but I'm 
afraid I can not write a regular expression, which can absolutely safely 
replace cvs keywords.
For a thousand file, I can not be sure it will not break something.
This is why I forced the clean  smudge way.
 

Konrad

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Git diff problem with cvs $id$

[Magnus Therning]

On Wed, Jul 01, 2015 at 06:37:12AM -0700, Konrád Lőrinczi wrote:
 I have two branches and the only difference between them is the cvs
 $id$, which is expanded in one branch and not expanded in the other. 
 
 Is there a way to show git diff as unchanged? 

Not out of the box.  You could do some filtering using attributes.

 Also should not show conflict in case of git merge. 
 
 
 Any suggestions?

Remove the it!  If you aren't using CVS those lines serve no purpose
at all.  Even if you do use CVS the line is of dubious usefulness.

/M

-- 
Magnus Therning  OpenPGP: 0xAB4DFBA4 
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

Eagles may soar, but weasels don't get sucked into jet engines.

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [git-users] Git diff problem with cvs $id$

[Konstantin Khomoutov]

On Wed, 1 Jul 2015 06:37:12 -0700 (PDT)
Konrád Lőrinczi klorin...@gmail.com wrote:

 I have two branches and the only difference between them is the cvs
 $id$, which is expanded in one branch and not expanded in the other. 
 
 Is there a way to show git diff as unchanged? 
 Also should not show conflict in case of git merge. 

Two approaches:

1) Simply remove it from the files in both branches, as Magnus
   suggested.

   Another idea is to modify files only in the branch in which
   the tokens are expanded -- simply modify them back into token
   form to read just $Id$.

   After that change, the files will be byte-to-byte identical.

2) If you actually need this tokens expanded for real (that is, to
   contain some up-to-date information, read up on clean/smudge
   filters (use `git help attributes`).

   Basically, you'll need a pair of programs one of which would
   expand those tokens in the data it reads from its stdin
   and write the result to its stdout, and another one would do
   the reverse -- turning the $Id: blah blah$ back to just $Id$.
   This way you have files with expanded tokens in your work tree
   and files with normalized tokens in the repository.  Git will also
   take care to apply clean filters when you do plain `git diff` --
   thus comparing the file in the work tree to its version in the
   repository.

I'd say, usage of VCS keywords these days is questionable.
First, knowing which revision the file came from is only supposeldy
useful for non-compiled code (like programs written in Tcl, Perl, Python
etc), and for cases files could be somehow updated / checked out by the
user individually.
Second, given just the file without any expanded VCS keywords in it,
you still are able to guess which commit(s) it could have came from --
quick googling yields [1, 2] as the top two links.

1. http://stackoverflow.com/a/223890/720999
2. http://blog.endpoint.com/2014/11/finding-specific-git-commit-at-point-in.html

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] git diff - get all changes since a tag was applied

[Gergely Polonkai]

Hello,

I'm not sure I get what you need, but my first guess is to use `git log
tagname..` (mind the two dots). Also you may want to add --oneline.

Best,
Gergely
On 3 May 2015 17:06, Demi Goldberg demi.goldb...@gmail.com wrote:


 Hi All,

 I would like to find all the changes (change set list only ) between a
 specific tag and the head.

 I would like to know what was change in the project (changesets) since a
 tag I had created in the past for example.

 I saw the command:
 git format-patch tag-name

 that create patch files for every change since that label , in my case I
 only want to see the list of changeset (patches) without creating the files.

 Which command should I run ?


 Thx,

 --
 You received this message because you are subscribed to the Google Groups
 Git for human beings group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to git-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Git Diff

[Magnus Therning]

On 3 Aug 2014 01:52, Anonymous prasanna.sreepa...@gmail.com wrote:

 Hi All,

 I'm new to Git. I generated a patch using git diff  patch command and
submitted the patch for one of the open source projects.

 The automated tool which applies these patches and tests them, returned
with below response. I don't understand what i'm doing wrong. I downloaded
the source recently.

 -1 Patch failed to apply to head of branch

I believe you might have more success with patches generated using 'git
format-patch'.

/M

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] git diff -w --name-only does not work

[Magnus Therning]

On Mon, Jun 09, 2014 at 11:30:15PM -0700, André Hänsel wrote:
 When I run git diff -w --name-only I get a file listed. When I
 then run git diff -w filename I get no output. When I run git
 diff filename I see that there are whitespace changes.
 
 How do I get the names of files with non-whitespace changes? Aren't
 -w --name-only the correct options?

It does look like you have found a bug; `-w` and `--name-only` does
not seem to play nice together:


% git --version
git version 2.0.0
% git diff
diff --git a/foo b/foo
index da91582..e1dac5f 100644
--- a/foo
+++ b/foo
@@ -1,3 +1,3 @@
-alsdkfja aldkfj kjfdlakjd aldfjal alsdjfla ldjalfaj
+alsdkfja  aldkfj kjfdlakjd aldfjal alsdjfla ldjalfaj
 aldkfj dalfjad lajdf ajfal  ljl asldfjal lajf aalkjad 
 alsdjfl akjdfl ajdfl adjajf aj.
% git diff -w
% git diff -w --name-only
foo


In the same vein, `-w` and `--name-status` doesn't seem to play well together
either:


% git diff --name-status -w
M   foo


It also seems `-b` suffers from similar problems when combined with
`--name-{only,status}`.

/M

-- 
Magnus Therning  OpenPGP: 0xAB4DFBA4 
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

In a hierarchy, every employee tends to rise to his level of incompetence.
 -- The Peter Principle


pgpNmwJeHu3DB.pgp
Description: PGP signature

Re: [git-users] git diff when file has been renamed

[Bob Hiestand]

On Thu, Feb 14, 2013 at 8:02 PM, Matt Neuburg mattne...@gmail.com wrote:

 My files have all been renamed, so to diff one of them to an earlier
 commit I'm saying this sort of thing:

 git diff HEAD:newname cb3e0a5fa8:oldname

 I have to keep a list of the new names and old names beside me at all
 times. This seems nuts. Is there a better way? Clearly git can tell from
 the history when a file has been renamed, so why do I have to tell it the
 old name of each file? Thx.


Have you tried the '-M' option to diff?

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [git-users] git diff when file has been renamed

[Matt Neuburg]

On Feb 15, 2013, at 7:48 AM, Bob Hiestand bob.hiest...@gmail.com wrote:

 
 On Thu, Feb 14, 2013 at 8:02 PM, Matt Neuburg mattne...@gmail.com wrote:
 My files have all been renamed, so to diff one of them to an earlier commit 
 I'm saying this sort of thing:
 
 git diff HEAD:newname cb3e0a5fa8:oldname
 
 I have to keep a list of the new names and old names beside me at all times. 
 This seems nuts. Is there a better way? Clearly git can tell from the history 
 when a file has been renamed, so why do I have to tell it the old name of 
 each file? Thx.
 
 Have you tried the '-M' option to diff? 

Yes, have you? It seems to have no effect when you supply an explicit filename 
- presumably *because* you are supplying an explicit filename. That's exactly 
my point.

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [git-users] git diff when file has been renamed

[Bob Hiestand]

On Fri, Feb 15, 2013 at 10:31 AM, Matt Neuburg mattne...@gmail.com wrote:

  Have you tried the '-M' option to diff?

 Yes, have you? It seems to have no effect when you supply an explicit
 filename - presumably *because* you are supplying an explicit filename.
 That's exactly my point.


I have; your post didn't restrict the use to only filtering by path.  I
don't see a way to filter by path and allow it to work without scripting it
yourself.

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [git-users] git diff when file has been renamed

[Matt Neuburg]

On Feb 15, 2013, at 9:24 AM, Bob Hiestand bob.hiest...@gmail.com wrote:

 your post didn't restrict the use to only filtering by path

It did; it showed an example of what I'm having to do, where I'm explicitly 
comparing HEAD:newfile with oldCommit:oldfile. That is what I need to do: 
compare a particular file with its version in the past. The question is, is 
there a way to do this without my having to supply the old name of the same 
file, every darned time. One thinks there should be, because, after all, git 
does know the old name (as is proved by its ability to log backwards through 
it).

Whenever one has to do something dumb and repetitive, a computer should be 
doing it for you. That's what I'm asking for in this case. I have dozens of 
these files to do these comparisons with, a lot. m.

PS It isn't my fault that the files were all renamed. Orders from on high, 
don't you know.

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [git-users] git diff when file has been renamed

[Thomas Ferris Nicolaisen]

On Friday, February 15, 2013 9:04:25 PM UTC+1, Matt Neuburg wrote:


 On Feb 15, 2013, at 9:24 AM, Bob Hiestand bob.hi...@gmail.comjavascript: 
 wrote: 

  your post didn't restrict the use to only filtering by path 

 It did; it showed an example of what I'm having to do, where I'm 
 explicitly comparing HEAD:newfile with oldCommit:oldfile. That is what I 
 need to do: compare a particular file with its version in the past. The 
 question is, is there a way to do this without my having to supply the old 
 name of the same file, every darned time. One thinks there should be, 
 because, after all, git does know the old name (as is proved by its ability 
 to log backwards through it). 

 Whenever one has to do something dumb and repetitive, a computer should be 
 doing it for you. That's what I'm asking for in this case. I have dozens of 
 these files to do these comparisons with, a lot. m. 

 PS It isn't my fault that the files were all renamed. Orders from on high, 
 don't you know.


If you are comparing many files in one diff, have a look 
at http://stackoverflow.com/questions/7759193/git-diff-renamed-file

If you want to single down to the diff on a single file, there is no first 
class way to do this in Git. You could do a feature request to the Git 
developer list https://gist.github.com/tfnico/4441562, and argue that it 
belongs in git diff. I agree that it would be useful, but not sure the 
developers will feel the same way.

Some GUI tools support showing the history of a single file. You can then 
select two revisions and do a compare between the two.

I guess you could script it by parsing the output of a git log with the two 
revisions and the filename in one of them, finding the old file-name, and 
then using it in a second diff call.

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [git-users] git diff when file has been renamed

[Matt Neuburg]

On Feb 15, 2013, at 1:57 PM, Thomas Ferris Nicolaisen wrote:

 If you want to single down to the diff on a single file, there is no first 
 class way to do this in Git. You could do a feature request to the Git 
 developer list, and argue that it belongs in git diff. I agree that it would 
 be useful, but not sure the developers will feel the same way.

Interesting. It is odd to me that you can say git diff commit1..commit2 -- 
myFile and that this usually works but suddenly stops working merely because 
myFile got renamed somewhere between commit and commit2. It feels like breakage 
and it surprises me that the developers don't feel it that way (but obviously 
they don't, or they would have done something about it).

 Some GUI tools support showing the history of a single file. You can then 
 select two revisions and do a compare between the two.
 
 I guess you could script it by parsing the output of a git log with the two 
 revisions and the filename in one of them, finding the old file-name, and 
 then using it in a second diff call.

Thanks. I think that's just what I'll do! m.

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.