Stages a staged file in git?

Question

I'm using git to manage my project. And I'm confused with the workflow of git when staging a file.

If I staged files and forgot commit and then I modify that files and stages again and commit, how can I roll back to first staged ?

Fabulous

@BleedingFingers not true. staged files are added to the object store, they just become unreferenced if not committed. They can probably be recovered, but the question is if you want to go to that trouble (i.e. does your life/job depend on it) – Orgel

@NevikRehnel: how can we recover it? – Fabulous

Answer 1

As described in "Git Internals - Git Objects", each time you change the content of a file, and add it to the cache, you do a:

git hash-object -w test.txt

That stores it to the object stored.

I just did two git add consecutively for one file, followed by a:

C:\Users\VonC\prog\go\src\github.com\VonC\asciidocgo\.git>gfind -mmin -10 -print
.
./index
./objects/4f
./objects/4f/76d586459ec6ffc42257bb4c61d5422051cb10
./objects/61
./objects/61/24401794e7fee613f5a56593a0a8a059b2627a

(Note the -mmin parameter to find files modified since the last 10 minutes only)

I could have listed those same sha1 after each git add with a:

git rev-parse :0:abstractNode_test.go

See git rev-parse (and "What does git rev-parse do?"): adding a file in the index is stage 0 only (stage 1, 2 and 3 are used during a merge to record, still in the index, the common ancestor, source and destination versions).

If I store the content of those two blobs:

C:\Users\VonC\prog\go\src\github.com\VonC\asciidocgo>
git cat-file -p 4f76d586459ec6ffc42257bb4c61d5422051cb10 > a
git cat-file -p 6124401794e7fee613f5a56593a0a8a059b2627a > b

(Note how I concatenate the '4f/' part of the blob path with the rest of the path in order to obtain the full sha1)

The diff between a and b does give me the additional bit I added to the index for that same file.

---

torek also mentions in the comments:

Another (I think easier) way: git fsck --lost-found.
Dangling blob objects wind up in .git/lost-found/other/ and are already cat-file -p-ed.

You would indeed found all the previous git add you did before the final one which ended up committed.
In my case, only one showed up:

C:\Users\VonC\prog\go\src\github.com\VonC\asciidocgo\.git\lost-found\other>dir
 Volume in drive C has no label.
 Volume Serial Number is D866-48E1

 Directory of C:\Users\VonC\prog\go\src\github.com\VonC\asciidocgo\.git\lost-found\other

25/01/2014  17:31    <DIR>          .
25/01/2014  17:31    <DIR>          ..
25/01/2014  17:31            16 873 4f76d586459ec6ffc42257bb4c61d5422051cb10

Summon

Another (I think easier) way: git fsck --lost-found. Dangling blob objects wind up in .git/lost-found/other/ and are already cat-file -p-ed. – Wareroom

@Wareroom good point, I included it in the answer for more visibility. – Summon