2

I recently performed a sloppy big commit to the wrong branch. I decided that I wanted the changes committed to be on a different branch and to possibly split the big commit into several smaller commits. I performed a git cherry-pick -n as indicated by this answer. This resulted in a bunch of staged changes in my current branch. I knew I wasn't going to need one of those changes. So I wondered: Is there any way to remove a modified file from the index and LOSE the changes in a single step? Most of the solutions I've seen require a git reset followed by a git checkout -- path/to/file.

Community
  • 1
  • 1
Trebor Rude
  • 1,904
  • 1
  • 21
  • 31

1 Answers1

3

What I ended up doing was a git checkout HEAD -- path/to/file which, as I understand it, replaced the file with the one from the HEAD commit's tree, rather than checking in the index first.

I came up with this solution without consulting the git man pages, but thanks to @torek for pointing out the git-checkout(1) man page. It was the fifth form of git checkout that I used, which looks like this:

git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>...

Part of the documentation for that form says:

The <tree-ish> argument can be used to specify a specific tree-ish (i.e. commit,
tag or tree) to update the index for the given paths before updating the working
tree.

So what actually happened was this: git replaced the file in the index with the version from HEAD (effectively removing the file from the index), then replaced the file in the working tree with the version from the index, eliminating the changes.

Trebor Rude
  • 1,904
  • 1
  • 21
  • 31
  • That replaces the working copy of the file with the one from the tree, *without affecting the index*. The `git reset -- ` step in your question affects the index (undoes the pending change) without affecting the *working copy*. That's why other answers say to do both. If you want the index affected, you will need either a `git reset`, or you can `git add` the file after the `git checkout` (replacing the modified one in the index). Either way it's two commands, though. – torek Jul 26 '13 at 22:03
  • The command did work for me. I even tried it again before clicking the "answer your own question" box. This is with git 1.7.5.4 (old, I know). – Trebor Rude Jul 26 '13 at 22:32
  • Hm, interesting. 1.7.5.4 is not that old ... and perusing the man page again, I see: "The argument can be used to specify a specific tree-ish (i.e. commit, tag or tree) to update the index for the given paths before updating the working tree." So I was wrong, this *does* update the index. – torek Jul 26 '13 at 22:55
  • Thanks for pointer to the documentation, @torek. I've updated the answer with that information. – Trebor Rude Jul 29 '13 at 15:40