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 removed. 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  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.