That is because the checkout of master only affected committed files - it didn't wipe the ignored files. When I checked out my branch and tried to pop, my ignored files were still there from before the stash save. Git status showed me tracked and untracked, but my activities didn't clean up the ignored files.ĭetails: I had used git stash save -a, checked out the master to compile and see original behavior, then tried to put it all back to continue editing. My similarly blocked pop operation was because leftover ignored files (see the. Even without changing working directories those options can sometimes create a stash you can't just apply back. PPS, You may need this technique after just using stash with -patch and/or -include-untracked. Sometimes needed even when you haven't made working directory changes Keep in mind that branches and tags are really just references to commits, so in many ways stashes, branches, and tags are just different ways of pointing at a commit (and its history). When you apply/pop you are doing something similar to cherry-picking it into your current branch. PS, It is tempting to think of a stash as a patch (just like it is tempting to think of a commit as a patch), but a stash is actually a commit against the HEAD when it was created. git symbolic-ref HEAD refs/heads/ORIGINALBRANCHīackground Stashes are commits likes branches/tags (not patches) The end result will be your additional stash changes in your working copy. It will switch back to your original branch and index without changing your working copy. If you just stashed while keeping some staged changes, then committed, and all you want to do is get the additional changes that where not staged when you stashed you can do the following. Option 2 - Reset original branch to match stash (limited changes since stash) If there are conflicts then handle them normally (one of the advantages of this approach is you can see and resolve conflicts). Commit your changes in STASHBRANCH, rebase it on ORIGINALBRANCH, then switch to ORIGINALBRANCH and rebase/merge the STASHBRANCH changes over it. If you have done a lot of changes in your ORIGINALBRANCH, then you are probably best treating STASHBRANCH like any local branch. Option 1 - Rebase stash branch normally (lots of changes since stash) What you do next depends on the relationship between the stash and where your target branch (which I will call ORIGINALBRANCH) is now. The following creates a branch based on the HEAD when the stash was created and then applies the stash (it does not commit it). It works well because a stash really is a commit under the covers (see PS). This is actually a useful general technique for working with stashes even when you don't have the listed error. Once it is a branch you can work normally in git using the normal branch-related techniques/tools you know and love. The best way to do this is to convert the stash to a branch. But I personally prefer to stay "within git". As mentioned by you can manually delete the files it is complaining about, switch branches, and then manually add them back.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |