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

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 
For more options, visit

Reply via email to