![]() ![]() You started some changes and stashed them.Inspect the results carefully (with git diff) to see if you like them, and if you do, use git stash drop to drop the stash. This gets Git to merge in your earlier changes, using Git's rather powerful merge mechanism. ![]() Check out the other branch and use git stash apply. Run git stash save (or plain git stash, same thing). You just want to take the changes you have now and "move" them to another branch. You started with a clean branch, were working on some changes, and then realized you were doing them in the wrong branch. ![]() The above is for "way 1", the "easy way": There are at least three or four different "ways to use git stash", as it were. What if you're doing more-advanced or more-complicated stuff? It's all pretty minor one way or the other though, and for a newbie to Git, it should be about the same. If you apply, you get to choose when to drop. If pop is able to extract the stash, it will immediately also drop it, and if you subsequently realize that you wanted to extract it somewhere else (in a different branch), or with -index, or some such, that's not so easy. The difference is that apply leaves the stash around for easy re-try of the apply, or for looking at, etc. I always suggest using git stash apply rather than git stash pop. Then use git diff to see the result.Īfter you're all done with your changes-the apply looks good and you're sure you don't need the stash any more- then use git stash drop to get rid of it. Just check out the branch you want your changes on, and then git stash apply. If the index is in a good state, in particular, it is often better to just to make a real commit to store the current state of things.The easy answer to the easy question is git stash apply This is one of the reasons that stash is often not the best choice. That's okay, but we enter the same state as with any merge conflict nothing can now happen until that conflict is resolved or the merge is aborted. I think you understand that part too! Applying the stash would now also change the index in a way that conflicts with that. You then copy the "c" change into the index (with git add). Clearly Git must therefore reconcile stash index with your index and stash working tree with your working tree, and it uses merge logic to do so - so a conflict is perfectly possible.Īfter your "c" change to file1.txt, we have a situation where you have changed the working tree but applying the stash would also change the working tree, so we abort. | * 37ca60e index on master: f2c4178 add file1Īpplying a stash, just the other way, requires that Git should update both the state of the index and the state of the working tree. You can actually see this structure by doing a git log on your stash entry (your identifier numbers will be different of course): * 501bd7e (refs/stash) WIP on master: f2c4178 add file1 Making a stash puts both the index and the work area into commits and rolls both back to the head commit state the index commit then has the current head as parent, and the work tree commit has the index commit and the current head as parents, making the stash’s content a merge commit. Just wondering what happens behind the scenes in this scenario.Ī stash stores both the state of the index and the state of the working tree, because those are both things you might have in an incoherent or unfinished state. I read the whole stashing and cleaning chapter in the git book but couldn't make sense of why this happens. So why git stash apply was aborting when file1.txt was not staged and then threw a conflict when it was staged? ![]() In both cases, the stash was b and file1.txt in the working directory was c. What's the conflict ( cat file1.txt): > Stashed changes Please commit your changes or stash them before you merge.Ĭool! now let's stage file1.txt and apply the stash again: git add file1.txtĪnd we have a conflict: Auto-merging file1.txtĬONFLICT (content): Merge conflict in file1.txt Results in: error: Your local changes to the following files would be overwritten by merge: ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |