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 [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
