![]() ![]() $ git diff file.txt # We have irrevocably lost "version 2" $ git diff -cached file.txt # No dif, of course. $ git add file.txt # Oops we didn't mean this $ git add file.txt # Stage (don't commit) "version 2" of file.txt $ git add file.txt # First add of file.txt That's why, strictly speaking, we cannot undo. ![]() If our misguided git add overwrote a previous staged uncommitted version, we can't recover it. Second: Be aware that git reset HEAD can't magically recover the previously cached file contents, it just resynchronises it from the HEAD. But, really, this a practically irrelevant case. This is in general preferable, because it works in both scenarios: it also does the undo when we wrongly added a version of an already tracked item.įirst: There is (as pointed out in the answer) only one scenario in which git reset HEAD doesn't work, but git rm -cached does: a new repository (no commits). If this is the case, then it's ok to run git rm -cached. The OP's scenario seems to be the first one (untracked file), we want the "undo" to remove the file (not just the current contents) from the tracked items. I mistakenly added files using the command. In light of this, the question is slightly ambiguous: In Git, this action is still called add, (not mere update it), because two different versions (snapshots) of a file are regarded as two different items: hence, we are indeed adding a new item to the cache, to be eventually committed later. If was already tracked, git add saves the current content (snapshot, version) to the cache. If was not previously tracked, git add adds it to the cache, with its current content. Let's recall first what git add actually does: Git add cannot be undone - safely, in general. Strictly speaking, and if I'm not mistaken: none. Update (what follows is my attempt to clear some confusion that can arise from the most upvoted answers): If you are anxious, you can run: git gc -prune=now It will not be copied to other repositories (via clone, push), and the space will be eventually reclaimed - though perhaps not very soon. This is nothing to be worried about the file is indeed still in the repository, but only as a "loose object". I zipped up everything to a safe place before trusting git help rm about the -cached not destroying anything (and what if I misspelled it).Īn addition to the accepted answer, if your mistakenly-added file was huge, you'll probably notice that, even after removing it from the index with ' git reset', it still seems to occupy space in the. Next time I'm going to use -n to do a dry run and see what will be added: git add -n. is recursive, turns out rm needs -r to recurse. Working tree files, whether modified or not, will be left. Use this option to unstage and remove paths only from the index. Note the warnings elsewhere here - git rm deletes your local working copy of the file, but not if you use -cached. Īnd the solution indeed is to use git rm -cached FILE. It further turns out that there's a bug logged against the unhelpfulness of this in the mailing list.Īnd that the correct solution was right there in the Git status output (which, yes, I glossed over as 'crap). ![]() => fatal: Failed to resolve 'HEAD' as a valid ref. => Damn, I didn't want to add all of that. cd to my great new project directory to try out Git, the new hotness.That is, you'll run into the same beginner's problem as me if your workflow, like mine, was something like: It turns out that this is because the HEAD ref (branch?) doesn't exist until after the first commit. (to undo my entire initial add), only to get this (not so) helpful message: fatal: Failed to resolve 'HEAD' as a valid ref. When I was new to this, I first tried git reset. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |