Retrieving a file at a before a specified commit

Hi all,

I have a commit like this:

    commit 4d77a3cee01db0412956d40875c79f51ac745acc
    tree 3443c9f633114c3bd2e015453a8c55a171e62b53
    parent 340d808ade8a79857bec40770f0eb4f98224c53d
    author ....
    committer .....

which modifies file A/B/C (ie specifically does not add, but changes an existing file in the repo).

I would then like to retrive the version of the file A/B/C before commit 4d77a3cee by using the parent commit 340d808a:

   git show 340d808ade8a79857bec40770f0eb4f98224c53d:A/B/C

which works for most files/commits I try this with, but doesn't work in one particular case.

Questions:

- Is my understanding of the above git command incorrect?
- Is this a corrupt repo? Is there some way to check?
- Is there some explaination of why I can't get the previous version
  of that file?

Appreciate any light that could be shed on this.

Cheers, Erik

On Wed, May 29, 2013 at 04:47:35PM +1000, Erik de Castro Lopo wrote:

Yes, that should work as long as the file is modified and not added. You can also say "4d77a3cee^:A/B/C" if you do not want to look up the parent id yourself.

Note that for a merge commit with multiple parents, the question is more complex, as there are two previous states that are merged.

You say that it doesn't work in one particular case. What is that case? What happens?

No, I think it is correct.

Running "git fsck" can tell you if there is repository corruption.

Probably. Can you show us the commit that fails? What does git say when you try it?

-Peff

Jeff King wrote:

Thanks, that's useful to know.

This is not the case in the one I am currently looking at. There is a single parent commit.

Here is an example. Grab this repository:

    git clone git://github.com/qca/open-plc-utils.git
    cd open-plc-utils/

Look at this commit:

    git log --name-status f51ac745a6d4087cc4d77a3cee01db0412955c79

and notice that one of the files modified is "pib/chkpib2.7", so lets look at the parent version of that file:

    git show f51ac745a6d4087cc4d77a3cee01db0412955c79^:pib/chkpib2.7

which produces no output and exits with 0 status.

However looking at the diff for commit f51ac745a suggests that while the file pib/chkpib2.7 may have existed before that commit, it must have been empty (ie zero length).

Does this explanation make sense?

Erik

Erik de Castro Lopo wrote:

Just to answer my own question, Yes it does.

The file was added in commit 53266574 and was actually zero length at that time.

Cheers, Erik ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

Erik de Castro Lopo <erikd@mega-nerd.com> writes:

While you are at it, you may want to check your LESS environment variable settings, especially if you find that the command gives you control without showing anything for a small (not zero length) file.

Junio C Hamano wrote:

Thanks. Thats a good tip. In my case LESS was not set to anything.

Cheers, Erik

On Thu, May 30, 2013 at 10:49:32AM +1000, Erik de Castro Lopo wrote:

Yes, that is what I would expect git to do in such a situation. You can inspect it further, too:

  $ git rev-parse f51ac745^:pib/chkpib2.7
  e69de29bb2d1d6434b8b29ae775ad8c2e48c5391

That's the sha1 of the blob containing the content. You can investigate information about that object like this:

  $ git cat-file -t e69de29b
  blob
  $ git cat-file -s e69de29b
  0
  $ git cat-file blob e69de29b

Of course since its size is 0, the last one is not that interesting. :)

You could also just look at the tree, which gives similar information:

  $ git ls-tree -lr f51ac745^ | grep pib/chkpib2.7
  100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 pib/chkpib2.7

Hope that helps.

-Peff

Jeff King wrote:

Yes it does. Thanks!

Erik