On Fri, May 03, 2013 at 11:45:34AM -0700, google spamtrap wrote:

> First I imported a bunch of files, and committed them.
> Then developers made several commits.
> Then I added a tag on the specific commit I used for the original
> import ( ok I *think* I did this right, but as a noob, I may have
> screwed up)
> Then developers made some other commits.
> Now, when I do a diff on a file that has not changed since its
> initial import, if I use the tag name only, I get the whole
> file:
> $ git diff SDK_0.0 Makefile
>         if I do a describe
> $ git describe
> SDK_0.0-34-g6a06923
>         then change the diff:
> $ git diff SDK_0.0-34-g6a06923 Makefile
>         diff behaves as I expect.
> What am I doing wrong or what should I check?

I have a feeling you misunderstand how `git diff` interprets its
arguments when it's given one revision and a filename.  You did not tell
what you intended to achieve so I have to guess.

The call `git diff SDK_0.0 Makefile`, unless "Makefile" can be parsed as
a revision, will compare the state of Makefile as recorded by a commit
to which SDK_0.0 resolves with its state in the work tree.

The call to `git describe` takes HEAD (as no explicit revision is passed
to it), finds the nearest annotated tag down its ancestry line,
succeeds and prints the result meaning the HEAD currently points to
the commit 6a06923 which is the 34th commit since the SDK_0.0 tag.

The call `git diff SDK_0.0-34-g6a06923 Makefile` makes Git first parse
the "SDK_0.0-34-g6a06923" as a revision.  According to the
gitrevsions(7) manual page, it's a valid revision (I was surprised to
learn this, to be honest), and it seems to be resolved using the same
rules which apply when this description is created -- that is, Git takes
the tag SDK_0.0, counts 34 commits up and arrives at the HEAD [*].
In the end, this call is the same as `git diff HEAD Makefile` which asks
to compare the state of the file in the commit pointed to by HEAD with
its state in the work tree.

If I parse your question correctly, in this latter case you do not see
any differences or see a reasonably small number of them (just the
uncommitted changes).

Now my take is that during those 34 commits between the SDK_0.0 tag and
the HEAD that Makefile has been indeed heavily modified, and that's what
you observe with the first call.

I cannot explain why you observe a whole-file difference in the first
case.  Two speculative guesses:

* The SDK_0.0 tag points to a commit which does not contain Makefile.
  For instance, you managed to tag a preceeding commit or something like
  this.  You can verify if the file is present at that tag by running
  `git ls-tree SDK_0.0` (it has a bunch of useful command-line switches,
  so look at the manual) or use a tool like gitk.

* Things like this may happen when a file has been EOL-converted at
  some point, and you're wrong thinking it hasn't changed.

  To see what might have happened to the file you could use
  `git log --follow --find-renames --find-copies -- Makefile`
  The "--summary" command-line option to `git log` might also come in

[*] In fact I think it just extracts the commit SHA-1 name from the
    suffix part, but this is irrelevant to the semantics of the parsing

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.

Reply via email to