On Fri, Dec 3, 2010 at 12:52 PM, Jeff King <peff@xxxxxxxx> wrote: > On Fri, Dec 03, 2010 at 12:41:52PM -0500, Eugene Sajine wrote: > >> > yes. I do see it with your command. >> > >> > git ls-tree -r HEAD | grep <resulting SHA1 from git hash-object> >> > >> > Thanks, >> > Eugene >> > >> >> While I'm able to see that object using the command Junio has provided >> the question remains the same: >> How could the file get into the state where its hash (git has-object >> file-name) cannot be found in any commit (git log --raw --no-abbrev | >> grep SHA1), if there was no local changes made to the file??? > > If the blob was created as the resolution of a merge conflict, I don't > think that will appear in the output of "git log --raw". > > -Peff > Yes this does make sense to me. Although it is not necessary to have conflicts during the merge - recursive merge as i understand also can create new blobs. Now as this is pretty much clear: don't you think that the information about one blob content changed during the merge should be present in the merge commit info? It seems strange that git log <filename> contains merge commit, but git whatchanged <filename> doesn't show the merge commit, while this merge commit actually had a change of content in the file, and finally "git log --raw <filename>" does list the merge commit but is not showing that particular blob had a change and now has a new SHA1? IMHO everytime there is a change in the content this change should be logged properly. Thanks, Eugene -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html