Revisions to How do I undo 'git add' before commit?

added 3 characters in body

Source Link

edited Sep 13, 2018 at 0:05

41.8k
19
115
149

You want:

git rm --cached <added_file_to_undo>

Reasoning:

When I was new to this, I first tried

git reset .

(to undo my entire initial add), only to get this (not so) helpful message:

fatal: Failed to resolve 'HEAD' as a valid ref.

It turns out that this is because the HEAD ref (branch?) doesn't exist until after the first commit. That is, you'll run into the same beginner's problem as me if your workflow, like mine, was something like:

cd to my great new project directory to try out Git, the new hotness
git init
git add .
git status

... lots of crap scrolls by ...

=> Damn, I didn't want to add all of that.

google "undo git add"

=> find Stack Overflow - yay

git reset .

=> fatal: Failed to resolve 'HEAD' as a valid ref.

It further turns out that there's a bug logged against the unhelpfulness of this in the mailing list.

And that the correct solution was right there in the Git status output (which, yes, I glossed over as 'crap)

...
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
...

And the solution indeed is to use git rm --cached FILE.

Note the warnings elsewhere here - git rm deletes your local working copy of the file, but not if you use --cached. Here's the result of git help rm:

--cached Use this option to unstage and remove paths only from the index. Working tree files, whether modified or not, will be left.

I proceed to use

git rm --cached .

to remove everything and start again. Didn't work though, because while add . is recursive, turns out rm needs -r to recurse. Sigh.

git rm -r --cached .

Okay, now I'm back to where I started. Next time I'm going to use -n to do a dry run and see what will be added:

git add -n .

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).

You want:

git rm --cached <added_file_to_undo>

Reasoning:

When I was new this, I first tried

git reset .

(to undo my entire initial add), only to get this (not so) helpful message:

fatal: Failed to resolve 'HEAD' as a valid ref.

It turns out that this is because the HEAD ref (branch?) doesn't exist until after the first commit. That is, you'll run into the same beginner's problem as me if your workflow, like mine, was something like:

cd to my great new project directory to try out Git, the new hotness
git init
git add .
git status

... lots of crap scrolls by ...

=> Damn, I didn't want to add all of that.

google "undo git add"

=> find Stack Overflow - yay

git reset .

=> fatal: Failed to resolve 'HEAD' as a valid ref.

It further turns out that there's a bug logged against the unhelpfulness of this in the mailing list.

And that the correct solution was right there in the Git status output (which, yes, I glossed over as 'crap)

...
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
...

And the solution indeed is to use git rm --cached FILE.

Note the warnings elsewhere here - git rm deletes your local working copy of the file, but not if you use --cached. Here's the result of git help rm:

--cached Use this option to unstage and remove paths only from the index. Working tree files, whether modified or not, will be left.

I proceed to use

git rm --cached .

to remove everything and start again. Didn't work though, because while add . is recursive, turns out rm needs -r to recurse. Sigh.

git rm -r --cached .

Okay, now I'm back to where I started. Next time I'm going to use -n to do a dry run and see what will be added:

git add -n .

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).

You want:

git rm --cached <added_file_to_undo>

Reasoning:

When I was new to this, I first tried

git reset .

(to undo my entire initial add), only to get this (not so) helpful message:

fatal: Failed to resolve 'HEAD' as a valid ref.

It turns out that this is because the HEAD ref (branch?) doesn't exist until after the first commit. That is, you'll run into the same beginner's problem as me if your workflow, like mine, was something like:

cd to my great new project directory to try out Git, the new hotness
git init
git add .
git status

... lots of crap scrolls by ...

=> Damn, I didn't want to add all of that.

google "undo git add"

=> find Stack Overflow - yay

git reset .

=> fatal: Failed to resolve 'HEAD' as a valid ref.

It further turns out that there's a bug logged against the unhelpfulness of this in the mailing list.

And that the correct solution was right there in the Git status output (which, yes, I glossed over as 'crap)

...
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
...

And the solution indeed is to use git rm --cached FILE.

Note the warnings elsewhere here - git rm deletes your local working copy of the file, but not if you use --cached. Here's the result of git help rm:

--cached Use this option to unstage and remove paths only from the index. Working tree files, whether modified or not, will be left.

I proceed to use

git rm --cached .

to remove everything and start again. Didn't work though, because while add . is recursive, turns out rm needs -r to recurse. Sigh.

git rm -r --cached .

Okay, now I'm back to where I started. Next time I'm going to use -n to do a dry run and see what will be added:

git add -n .

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).

Copy edited. Removed historical information.

Source Link

edited Mar 9, 2013 at 11:13

Peter Mortensen

31.3k
22
109
132

You want:

git rm --cached <added_file_to_undo>

Reasoning:

Also a newbieWhen I was new this, I first tried

git reset .

(to undo my entire initial add) only, only to get this (not so) helpful message:

fatal: Failed to resolve 'HEAD' as a valid ref.

It turns out that this is because the HEAD ref (branch?) doesn't exist until after the first commit. That That is, you'll run into the same newbiebeginner's problem as me if your workflow, like mine, was something like:

cd to my great new project directory to try out gitGit, the new hotness
git init
git add .
git status

... lots of crap scrolls by ...

=> Damn, I didn't want to add all of that.

google "undo git add"

=> find StackoverflowStack Overflow - yay

git reset .

=> fatal: Failed to resolve 'HEAD' as a valid ref.

itIt further turns out that there's a bug loggeda bug logged against the unhelpfulness of of this in the mailing listin the mailing list.

And that the correct solution was right there in the gitGit status output (which, yes, I glossed over as 'crap)

...
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
...

And the solution indeed is to use git rm --cached FILE.

Note the warnings elsewhere here - git rm deletes your local working copy of the file, but not if you use --cached. Here's the result of git help rm`git help rm:

--cached Use this option to unstage and remove paths only from the index. Working tree files, whether modified or not, will be left.

I proceed to use

git rm --cached .

to remove everything and start again. Didn't work though, because while add . is recursive, turns out rm needs -r to recurse. sighSigh.

git rm -r --cached .

Okay, now I'm back to where I started. Next Next time I'm going to use -n to do a dry run and see what will be added:

git add -n .

UPDATE Oh yeah forgot to mention - 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).

You want:

git rm --cached <added_file_to_undo>

Reasoning:

Also a newbie I first tried

git reset .

(to undo my entire initial add) only to get this (not so) helpful message:

fatal: Failed to resolve 'HEAD' as a valid ref.

turns out that this is because the HEAD ref (branch?) doesn't exist until after the first commit. That is, you'll run into the same newbie problem as me if your workflow, like mine, was something like:

cd to my great new project directory to try out git, the new hotness
git init
git add .
git status

... lots of crap scrolls by ...

=> Damn, I didn't want to add all of that.

google "undo git add"

=> find Stackoverflow - yay

git reset .

=> fatal: Failed to resolve 'HEAD' as a valid ref.

it further turns out that there's a bug logged against the unhelpfulness of this in the mailing list.

And that the correct solution was right there in the git status output (which, yes, I glossed over as 'crap)

...
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
...

And the solution indeed is to use git rm --cached FILE

Note the warnings elsewhere here - git rm deletes your local working copy of the file, but not if you use --cached. Here's the result of git help rm`:

--cached Use this option to unstage and remove paths only from the index. Working tree files, whether modified or not, will be left.

I proceed to use

git rm --cached .

to remove everything and start again. Didn't work though, because while add . is recursive, turns out rm needs -r to recurse. sigh.

git rm -r --cached .

Okay, now I'm back to where I started. Next time I'm going to use -n to do a dry run and see what will be added:

git add -n .

UPDATE Oh yeah forgot to mention - 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)

You want:

git rm --cached <added_file_to_undo>

Reasoning:

When I was new this, I first tried

git reset .

(to undo my entire initial add), only to get this (not so) helpful message:

fatal: Failed to resolve 'HEAD' as a valid ref.

It turns out that this is because the HEAD ref (branch?) doesn't exist until after the first commit. That is, you'll run into the same beginner's problem as me if your workflow, like mine, was something like:

cd to my great new project directory to try out Git, the new hotness
git init
git add .
git status

... lots of crap scrolls by ...

=> Damn, I didn't want to add all of that.

google "undo git add"

=> find Stack Overflow - yay

git reset .

=> fatal: Failed to resolve 'HEAD' as a valid ref.

It further turns out that there's a bug logged against the unhelpfulness of this in the mailing list.

And that the correct solution was right there in the Git status output (which, yes, I glossed over as 'crap)

...
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
...

And the solution indeed is to use git rm --cached FILE.

Note the warnings elsewhere here - git rm deletes your local working copy of the file, but not if you use --cached. Here's the result of git help rm:

--cached Use this option to unstage and remove paths only from the index. Working tree files, whether modified or not, will be left.

I proceed to use

git rm --cached .

to remove everything and start again. Didn't work though, because while add . is recursive, turns out rm needs -r to recurse. Sigh.

git rm -r --cached .

Okay, now I'm back to where I started. Next time I'm going to use -n to do a dry run and see what will be added:

git add -n .

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).

Added answer at top, so reader doesn't see the first `git reset` and miss the actual answer later on.

Source Link

edit approved Jan 28, 2012 at 22:29

Grhm

6.8k
4
41
65

You want:

git rm --cached <added_file_to_undo>

Reasoning:

Also a newbie I first tried

git reset .

(to undo my entire initial add) only to get this (not so) helpful message:

fatal: Failed to resolve 'HEAD' as a valid ref.

turns out that this is because the HEAD ref (branch?) doesn't exist until after the first commit. That is, you'll run into the same newbie problem as me if your workflow, like mine, was something like:

cd to my great new project directory to try out git, the new hotness
git init
git add .
git status

... lots of crap scrolls by ...

=> Damn, I didn't want to add all of that.

google "undo git add"

=> find Stackoverflow - yay

git reset .

=> fatal: Failed to resolve 'HEAD' as a valid ref.

it further turns out that there's a bug logged against the unhelpfulness of this in the mailing list.

And that the correct solution was right there in the git status output (which, yes, I glossed over as 'crap)

...
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
...

And the solution indeed is to use git rm --cached FILE

Note the warnings elsewhere here - git rm deletes your local working copy of the file, but not if you use --cached. Here's the result of git help rm`:

--cached Use this option to unstage and remove paths only from the index. Working tree files, whether modified or not, will be left.

I proceed to use

git rm --cached .

to remove everything and start again. Didn't work though, because while add . is recursive, turns out rm needs -r to recurse. sigh.

git rm -r --cached .

Okay, now I'm back to where I started. Next time I'm going to use -n to do a dry run and see what will be added:

git add -n .

UPDATE Oh yeah forgot to mention - 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)

Also a newbie I tried

git reset .

(to undo my entire initial add) only to get this (not so) helpful message:

fatal: Failed to resolve 'HEAD' as a valid ref.

turns out that this is because the HEAD ref (branch?) doesn't exist until after the first commit. That is, you'll run into the same newbie problem as me if your workflow, like mine, was something like:

cd to my great new project directory to try out git, the new hotness
git init
git add .
git status

... lots of crap scrolls by ...

=> Damn, I didn't want to add all of that.

google "undo git add"

=> find Stackoverflow - yay

git reset .

=> fatal: Failed to resolve 'HEAD' as a valid ref.

it further turns out that there's a bug logged against the unhelpfulness of this in the mailing list.

And that the correct solution was right there in the git status output (which, yes, I glossed over as 'crap)

...
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
...

And the solution indeed is to use git rm --cached FILE

Note the warnings elsewhere here - git rm deletes your local working copy of the file, but not if you use --cached. Here's the result of git help rm`:

--cached Use this option to unstage and remove paths only from the index. Working tree files, whether modified or not, will be left.

I proceed to use

git rm --cached .

to remove everything and start again. Didn't work though, because while add . is recursive, turns out rm needs -r to recurse. sigh.

git rm -r --cached .

Okay, now I'm back to where I started. Next time I'm going to use -n to do a dry run and see what will be added:

git add -n .

UPDATE Oh yeah forgot to mention - 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)

You want:

git rm --cached <added_file_to_undo>

Reasoning:

Also a newbie I first tried

git reset .

(to undo my entire initial add) only to get this (not so) helpful message:

fatal: Failed to resolve 'HEAD' as a valid ref.

turns out that this is because the HEAD ref (branch?) doesn't exist until after the first commit. That is, you'll run into the same newbie problem as me if your workflow, like mine, was something like:

cd to my great new project directory to try out git, the new hotness
git init
git add .
git status

... lots of crap scrolls by ...

=> Damn, I didn't want to add all of that.

google "undo git add"

=> find Stackoverflow - yay

git reset .

=> fatal: Failed to resolve 'HEAD' as a valid ref.

it further turns out that there's a bug logged against the unhelpfulness of this in the mailing list.

And that the correct solution was right there in the git status output (which, yes, I glossed over as 'crap)

...
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
...

And the solution indeed is to use git rm --cached FILE

Note the warnings elsewhere here - git rm deletes your local working copy of the file, but not if you use --cached. Here's the result of git help rm`:

--cached Use this option to unstage and remove paths only from the index. Working tree files, whether modified or not, will be left.

I proceed to use

git rm --cached .

to remove everything and start again. Didn't work though, because while add . is recursive, turns out rm needs -r to recurse. sigh.

git rm -r --cached .

Okay, now I'm back to where I started. Next time I'm going to use -n to do a dry run and see what will be added:

git add -n .

UPDATE Oh yeah forgot to mention - 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)