Re: [git-users] Why do git log and git diff show different things on same two SHA's?
Thank you for all the great information! It was very helpful. The reason I thought this was an issue is because I've got several files in my repository that seem to have gone missing during certain commits but then they appear again. This sounds crazy and I've been using git for 2 1/2 years and never seen this before. The problem is I don't really know how to figure out what is going on. I usually just use a git log with the --name-status and I can see that someone did something but in this case it's not showing the file but if I do a git checkout of one SHA the file is there and then when I do a git checkout of the next SHA in the log the file is gone even though git log doesn't show that files as being part of that commit. Any ideas on why or how that happens or anything I can use to try and understand how the file is going away? On Tuesday, January 29, 2013 1:21:33 AM UTC-7, Konstantin Khomoutov wrote: > > On Mon, Jan 28, 2013 at 10:46:06PM -0800, > rrid...@transydian.comwrote: > > > 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, normal
Re: [git-users] Why do git log and git diff show different things on same two SHA's?
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 , see "SPECIFYING
REVISIONS" section in gitrevisions(7). However, "diff" is about
comparing two endpoints, not ranges, and the range notations
(".." and "...") 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 subscribe
[git-users] Why do git log and git diff show different things on same two SHA's?
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 commit 29aa66f83dfdcfc80670a6e125456b5db6a2c59a Author: Removed For Security Date: Thu Jan 24 19:58:39 2013 -0700 Remove Unique Key of Sending_sid, Receiveing_sid of BATCH_SEQUENCE table; Fix threshold level on DUSGE refactoring M src/DbSchema/pkg/data_extracts.pkb M src/DbSchema/schema/raise_mr_db.sql -- 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.
