On Mon, Jan 28, 2013 at 10:46:06PM -0800, rridp...@transydian.com wrote:

> I would think that when I run a git diff on two specific SHA's it
> would have the same output as a git log with the same two SHA's when
> run with the --name-status. 
> How did the file get changed if it wasn't done as part of the commit
> and that should show in the log!
> > git diff b504ef5 29aa66f8 --name-status                                   
> M       src/DbLibrary/BatchTable.cpp
> M       src/DbSchema/pkg/data_extracts.pkb
> M       src/DbSchema/schema/raise_mr_db.sql
> [/home/luke/rridpath/work/git/RAISEInvestigate/src/DbLibrary] 
> > git log b504ef5..29aa66f8 --name-status                                   
> M       src/DbSchema/pkg/data_extracts.pkb
> M       src/DbSchema/schema/raise_mr_db.sql
> The diff of these SHA's shows a real difference on the BatchTable.cpp file:
> > git diff b504ef5 29aa66f8                                                 
> diff --git a/src/DbLibrary/BatchTable.cpp b/src/DbLibrary/BatchTable.cpp

The problem here is that the r1..r2 shorthand specification used by
certain Git tools accepting *ranges* of revisions means "all commits
reachable from r2 but excluding those also reachable from r1" and is a
shorthand for "^r1 r2".  "The catch" here is that the commit r1 is also
excluded, and that will be b504ef5 in your example.

By now this should be apparent, that you tell `git diff` to compare the
state of b504ef5 to the state of 29aa66f8, and then you tell `git log`
to walk the tree of commits which starts with commit 29aa66f8 and cut out
from it the tree of commits reachable from b504ef5.
Supposedly, the changes to your BatchTable.cpp which you perceive as
"missed" by `git log` are contained in that commit b504ef5.

The trap you fell into appears to be rather common and have two causes.

First, when approaching `git log`, people tend to treat history as a
sort of timeline, on which you could point at two events and say "show
me just the part from there to here".  `git log` implements different
approach to navigating history.  Supposedly the use case Git developers
had in mind is that it should be easy to inspect lines of history
introduced by various branches (and tags) while paying no attention at
all to underlying SHA-1 names of commits.

To demonstrate the idea, if you have a branch "experiment" forked off
"master" some time ago, and both branches have accumulated commits since
then, to view what's on the "experiment" branch since the point it was
forked at, you do `git log master..experiment`.  Note that this approach
does not require to to go figuring out the name of the commit at which
the branches have diverged.  And also it's perfectly able to cope with
the fact "master" have evolved since then along with "experiment".

It's useful to think of Git's approach to traversing history as working
wih sets: say, in the previous example, "experiment" refers to a set of
commits, "master" refers to another set of commits, both sets intersect,
and you tell `git log` to show you the first set with the intersection

This approach does indeed require wrapping your head around it and
stopping thinking in timeline-style terms (like is common with
Subversion, for instance).

In my opinion, this part [1] of the "Pro Git" book gives quite a good
explanation of the concept.  Be sure to read the gitrevisions manual
page as well, and if you're interested in the machinery, a cursory look
at the `git rev-list` manual would also be useful.

Second, people tend to confuse the way `git diff` and `git log` treat
the revisions they're passed.

`git diff` takes one or two revisions, and when it takes two, it just
compares the trees referenced by both, ignoring any revisions which
might occur in between in the commit graph.  That is, normally this tool
pays no attention to history at all (except with the r1...r2, that is,
"triple dot" form).

`git diff` also accepts two other ways to pass it two revisions: "r1..r2"
and "r1...r3" -- much like `git log` does.  Unfortunately, that "r1..r2"
form does not mean the same thing as with `git log`, and it just makes
`git diff` compare the tree at r1 with the tree at r2 as if you just
specified these two revisions as separate arguments, in this order.
This seems to create more confusion than comfort, and I recall Junio
Hamano (the current Git maintainer) lamenting the decision to include
support for r1..r2 in `git diff` in the first place.

The `git diff` manual page does even include this bit:

        For a more complete list of ways to spell <commit>, see "SPECIFYING
    REVISIONS" section in gitrevisions(7). However, "diff" is about
    comparing two endpoints, not ranges, and the range notations
    ("<commit>..<commit>" and "<commit>...<commit>") do not mean a range
    as defined in the "SPECIFYING RANGES" section in gitrevisions(7).

1. http://git-scm.com/book/en/Git-Tools-Revision-Selection#Commit-Ranges

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