Once you have the index/staging-area set up the way you want, now you can make the commit you intended to make all along.
Once you have the index arranged, you can commit Still, it's an option, and something useful to remember if you accidentally (or in desperation) run a -mixed or default git reset.
But if that was a lot of work, you probably don't want to do a -mixed reset. Git won't touch the work-tree, so if you had carefully built the index from the work-tree, you can re-do all that work now.
If you run git reset HEAD^, without -soft, Git will wipe out (reset) your current index/staging-area, replacing it wholesale with the contents of the previous commit. So this is why you really might want to start with git reset -soft. If you haven't run git reset yet, you have to take care to add "commit C vs commitD " to any changes shown as "commitD` vs index". But they're in relation to the HEAD commit. These, again, are the "staged changes" (contents of index as compared to contents of HEAD commit), or the "unstaged changes" (contents of work-tree as compared to contents index). This doesn't show you the contents directly instead, it shows you how those contents differ from the contents of HEAD-which you probably know about-or from the contents of the work-tree, which you can see. To see what's in the index, you would normally run git diff -cached (to compare HEAD to index/staging-area) or git diff (to compare index to work-tree). It's very hard to tell whether it has the form you want, though, because you cannot view the version of the file that is in the index. If you do either of these git checkout -p commands (with or without the initial git reset -soft), you can get the copy of the file in the index to have the form you want. That could be as simple as git checkout -p HEAD^. If you didn't do the git reset, you could still run git checkout -p, but you'd want to add the hash ID of commit C, or some way to tell Git to look inside commit C. This will let you apply small changes to the copies of files in the index. Their actual IDs are some incomprehensible hash strings for simplicity I've labeled them A through C instead: A, as in AnimiVulpis's answer. Let's back up a lot, because Git doesn't store files the way many people think it does.įor instance, consider this tiny repository with just three commits. Once you have made a commit with some changes staged, they are permanently stored that way in that commit. But you don't have to do it this way.Ī long explanation (with some graph pictures) follows. That's generally going to be simplest and easiest. You probably should reset, probably with -soft, then use git checkout -p, then git commit.
0 kommentar(er)
