You can make it work, but there are some more appropriate tools. But rebase is not quite the right tool: it's designed for en-masse cherry-picking, and you have just one commit and at the end it uses git reset to move a branch label, but not quite in the way you want. It's true that you can use git rebase: under the covers, it uses git cherry-pick itself. To do the "copy commit to new, different commit on different branch" you can use git cherry-pick. One way to do this is to make it now, on the current branch then copy that commit to a new, different commit on a different branch. You want your new commit made on another branch. The new commit's parent commit is whatever the current commit was before. and then use stash as a convenient short-cut for cases where you're sure it will work.īackground: a commit takes whatever is in the index now- git ls-files -cached will show the complete contents, while git status trims this down to the "interesting" ones and adds additional useful information-and makes a commit out of them, with all the necessary tree objects and so on. In which case, you can just use those tools most the time. This is one reason I don't really like the stash system: it falls down in hard cases and leaves you needing to know the tools you can use if you don't use stash. There's a big potential pitfall in step 3, though: it's possible the stash won't apply correctly. Note that pop is just apply followed by drop: we didn't want to drop the stash in step 3 (the stash has the only copy of the original modified-but-unstaged files), which is why we used apply there, but now we (presumably) do want to drop the stash, so using pop is OK. You may need to clean out any unstaged files (and it's safe to do so, they are still in the stash): git reset -hard, followed by git checkout wrongbr, then git stash pop. Now you can get back on the other "wrong" branch (where you made the stash initially) and git stash apply or git stash pop with or without -index. The commit will commit the staged files, leaving the unstaged files unstaged. The previously staged files are again staged, and the unstaged files are still unstaged, because you apply-ed the stash with -index. If all goes well, you're now in a position to git commit the changes to the branch you want them on. The -index is very important: it tells the stash script to keep the index and unstaged files separate, i.e., give you back the staged and unstaged setup you had earlier. This uses the special stash commits made in step 1, while also leaving them there ( apply) in the stash. Git checkout the branch you want these on. Meanwhile you're still on the "wrong" branch, which I'll call wrongbr below. Usually you can just leave these untracked files floating around in your work tree untracked, though.) These commits are not on any branch, they are only on/in the special "stash" ref. (If you need to hold untracked files, you can add the -u flag, and then the stash script adds yet a third commit. This writes two commits, one based on the current index and a second to hold as-yet-unstaged work-tree files. I'm not a very big fan of git stash, but if you're used to using it, here's the simplest of the other methods: It could perhaps use a bit of expansion though, and there are easier (well, potentially easier) methods. Git's basic storage mechanism is "the commit"-in fact, all git stash does is make a couple of somewhat unusual commits-so Nick Volynkin's answer is a correct one.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |