9/14/2023 0 Comments Git stash show![]() ![]() You get a chance to review what got applied, and decide whether it was actually applied correctly. This is necessary for multiple reasons, and also has the side effect of making sure Git does not treat it as a merge when you resolve conflicts and commit.ģThis is why I recommend avoiding git stash pop, in favor of git stash apply. :-)ĢThe git stash code actually uses git merge-recursive directly here. But don't do that: Git won't mind, but you will confuse yourself. This matters if you make a branch named stash: the branch's full name is refs/heads/stash, so these are not in conflict. But that just leaves you with another u-style stash to deal with later.ġThis is in fact refs/stash. To make that happen, you can use git clean yourself-but remember that untracked files (ignored or not) have no other existence inside a Git repository, so be sure these files can all be destroyed! Or, you can make a temporary directory, and move the files there for safekeeping-or even do another git stash save -u or git stash save -a, since those will run git clean for you. This means the files must either not exist at all, or have the same contents as in the u commit. 4 Git insists on extracting all the files from that u commit, into the current work-tree. If you used git stash pop, the code retains the stash and delivers the same failure status as for git stash apply.īut if you have that third commit-if there is a u commit in the stash you are applying-then things change! There is no option to pretend that the u commit does not exist. ![]() 3 If the merge fails, Git declares the apply to have failed. If you used git stash pop to apply the stash, the code now drops the stash. ![]() If the merge succeeds, all is good-well, at least Git thinks so-and the git stash apply itself succeeds. It does this by calling git merge 2 (without allowing it to commit or treat the result as a normal merge), using the original commit on which the stash was made ( i's parent, and w's first parent) as the merge base, w as the -theirs commit, and your current (HEAD) commit as the target of the merge. If the stash has only two commits, git stash apply can now apply the w commit. If you omit -index, git stash apply completely ignores the i commit. (more or less there are a bunch of nitty details that get in the way of the basic idea here). So the i commit is in fact a perfectly normal commit! It's just not on any branch. In a normal commit, this snapshot is made from the index / staging-area contents. Remember also that each commit holds a snapshot. The stash normally holds two commits, which I like to call i for the index / staging-area contents, and w for the work-tree contents. These form a graph, where later commits point back to earlier ones. What's inside a stashĮvery commit can list one or more parent commits. To understand this we need to look at what's in those commits. 1 The most important thing, though, is what Git lets you-and makes you-do with these two or three commits. Git locates them through the special name stash. These two, or three, commits are special in one important way: they are on no branch. The default is two you get three if you use any spelling of the -all or -include-untracked options. As a bit of additional explanation, note that git stash makes either two commits, or three commits. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |