0

I've been working on a project for the past couple of hours and when you're using the trial and error strategy you most likely forget the commit changes that should be in separate commits to keep a clean history.

At least, that was what happened to me and now I'm trying to solve my mistake.

I know about git add -p to only stage the changes I want to stage instead of a whole file when I want to stage a single line of code.

Obviously you don't want to commit something broken so I wanted to test whether I could still compile the project when I stashed all the unstaged changes using git stash push -k -u and I saw that I forgot to stage a change. I did git stash pop but that's when the problem came walking through the door and smashed me in the face, there were merge conflicts in every single file that I had partially staged using git add -p.

I used the following documentation from Git to get to the point where I am now:
https://git-scm.com/docs/git-stash#git-stash-Testingpartialcommits

Julian
  • 837
  • 1
  • 11
  • 24
  • I have never had the need to stage a partial change in a file, and I would recommend that you avoid doing this if you are a beginner Git user. You have a problem now, because you popped the stash, meaning it isn't there anymore. For future reference, consider using `git stash apply`. This applies what's in the stash without actually deleting it. – Tim Biegeleisen Feb 02 '18 at 01:59
  • I used `git stash push` because it was suggested in the documentation and I didn't want to miss a solution because of my own ignorance of `git stash apply` being better. I saved the stash before pushing the uppermost stash so that I would always have a backup. I might have come across as a beginner who's copy pasting options like `-k` or `-p` from the documentation without thinking. – Julian Feb 02 '18 at 02:10
  • You have a big mess now from what I can see. I don't have an exact answer/fix. Most likely, you didn't need to use such a complicated workflow. If you can get yourself back to where you started, and clearly tell me what you want to do, I can suggest an answer. – Tim Biegeleisen Feb 02 '18 at 02:16
  • I fixed the mess and it's back to how it was so let me explain. I want to split my unstaged work into multiple commits to keep a clean commit history, which I can do. But what I'm trying to do now is test the work I staged so that I'm sure I didn't forget to stage anything else that should've been staged and pushed with the commit. – Julian Feb 02 '18 at 02:22
  • Why can't you just stage the files you want and make separate commits? I strongly recommend against trying to split up individual files. – Tim Biegeleisen Feb 02 '18 at 02:24
  • Because unfortunately some changes are in the same file but I would like to keep them separate because if I add both those changes in a single commit (stage the file instead of splitting it up) I'd also have to commit a lot of other changes that aren't related to change 1 in the first file but are to change 2 in the first file. – Julian Feb 02 '18 at 02:32
  • I have tried: (1) edit a file in 2 places, (2) stage one change, (3) `git stash save -k -u`, (4) `git stash pop`. It has restored stashed un-staged changes without any merge conflict. Did I understand your case wrong? – max630 Feb 02 '18 at 07:08
  • You didn't, that is basically what I did but in a smaller test "environment". Can it be because I've used the hunk editor (`e`) when I used `git add -p ` instead of letting Git split the hunk for me? – Julian Feb 02 '18 at 14:24

1 Answers1

0

I don't particularly like git stash in general, and there's a very sharp edge-case bug in git stash that you can hit here. But it is intended to be used the way you are using it, I believe.

To undo the effect of git stash -k you must start with git reset --hard followed by an apply or pop with the --index option (do not use --keep-index again!). All of this depends heavily on the git stash having actually stashed something (and watch out for the bug). For details, see How do I properly git stash/pop in pre-commit hooks to get a clean working tree for tests?

torek
  • 448,244
  • 59
  • 642
  • 775