0

First I checkout a branch

> git checkout -b renaming-Foo-to-Bar

then I edit the files to rename instances of class Foo to Bar. Subsequently

> git add -u

but now I omit to run git commit -m "renamed Foo to Bar".

Thinking that I did commit, I proceed to merge the branch to master.

> git checkout master
> git merge renaming-Foo-to-Bar

It's only after I read the merge message (something of the sort "nothing to merge") that I realize that I didn't commit.

IIUC, I now have a so-called "dangling commit", and by running

> git fsck --lost-found
Checking object directories: 100% (256/256), done.
dangling blob   03c044a..cb
dangling commit ab8076f..47
dangling commit 128532d..99
dangling commit 5605e2d..4a

I can recover it. But the dangling commit and dangling blob messages do not come with a timestamp or other identifying information.

How do I recover such a dangling commit?

Unfortunately my dangling commits/blobs are many:

> git fsck --lost-found | wc
Checking object directories: 100% (256/256), done.
      52     142    2806

Running git show 03c044a..cb on the first few and last few SHAs reveals changes deep in my history, not recent ones.

Calaf
  • 10,113
  • 15
  • 57
  • 120

2 Answers2

1

It's only after I read the merge message (something of the sort "nothing to merge") that I realize that I didn't commit.

... in which case, you should still have your changes "staged", i.e., you have made changes to the index. git status should show everything ready to be committed.

IIUC, I now have a so-called "dangling commit" ...

No: these are commits that do exist (hence must have been made at some point), but now have no external name by which to find them. Since you did not make a commit, this commit does not yet exist.

Assuming you still want to commit the renames on a branch, you should just need to switch back to your renaming branch, and commit. See Git - checkout another branch when there are uncommitted changes on the current branch for more on what you have done so far.

torek
  • 448,244
  • 59
  • 642
  • 775
1

If you didn't commit and just staged your changes and that they are now lost, your only solution to find your changes is to search for dangling blobs (no commit objects are created when you just stage your changes, nor tree objects :-()

You could try to sort the corresponding files by date and also display the content using the command git cat-file -p SHA1.

I did something like that to save a colleague last week, putting all the blob content in files in a folder and then using a text editor to find the desired file.

Philippe
  • 28,207
  • 6
  • 54
  • 78
  • `git cat-file -p SHA1` is handy, but it doesn't reveal the path/filename of what it outputs, not even a separator or timestamps. Multiple languages are thrown together in one output. – Calaf Aug 16 '17 at 16:39
  • 1
    Path and filename are stored in tree objects that are not created when staging. That's the way git works. So you won't have better! You could use the same command starting from a 'commit' object then a 'tree' and ending by a 'blob'. >Multiple languages are thrown together in one output. Not possible. One 'blob' Sha1 = 1 version of the content of a file. – Philippe Aug 16 '17 at 21:19