![]() Above, the "main" stash is now hanging from commit E, and the earlier stash is hanging from C. Each stash-bag is hung off a specific commit. Go back to the diagram with the stash-bags. If you run git stash show -p, git shows you a diff ( -patch). Moreover, the git stash sub-commands will verify that the commit you name-or, if you name no commit, the one found via the stash reference-"looks like" a stash, i.e., is one of these funny merge commits. Let's tackle git stash show first as that's the one you are supposed to use with stashes. OK, finally, we can get to your git show vs git stash show, and git diff and so on. Git uses SHA-1s for more than just commits, too, but here let's just think about commits.) Git stash show, git show, and git diff (For a complete description of how to name a revision, see gitrevisions. Most things in git use either git rev-parse or its big brother that does a lot more, git rev-list, to turn names into the SHA-1 values.) Try it: run git rev-parse HEAD, git rev-parse stash, and so on. So we have aliases: things like branch and tag names, and relative names like HEAD and HEAD~2, and reflog-style names like or (There's a command, git rev-parse, that turns name strings like this into hash values. Commits can never be changed, and that's a cryptographic hash of the entire contents of the commit, so if that particular commit exists at all, that value is always its name. Any time git needs you to name a specific commit, you can do it any of many different ways.Įach commit has a "true name" that is the big ugly SHA-1 hash you see, values like 676699a0e0cdfd97521f3524c763222f1c30a094. This next bit is a key to understanding what's going on. The actual stash-bag itself is garbage collected on the next git gc.) That's why all the "higher" ones get renumbered. you use git stash drop, the stash script simply manipulates the reflog for the stash ref to delete the ID of the dropped stash-bag. They just now require a "reflog" style name, 3Īnyway, what you have now is this: A - B - C - D - E <- HEAD=master But the old stash-bag commits are still in there. What happens to the old stash-bag? The "reference name" 2 stash, now points to the new stash-bag. Commits cannot be changed, and this is true of stash-bag commits too.īut now you make a new stash by making some changes (while still on master) and running git stash save again. The point here is that the "stash-bag", the pair of index and work-tree commits, is still hung off the same commit as it was before. Now you might make (or switch to) another branch, but for illustration, let's just say you leave that stash there and make more "regular" commits on master: A - B - C - D - E <- HEAD=master This is what you get: A - B - C <- HEAD=master You're on the one branch and make a few changes and then run git stash save (or just plain git stash). ![]() Let's assume for simplicity that you have a small repo with just one branch and three commits on it, A through C. Let me draw this again here (see the referenced answer for a much longer version), just to illustrate it properly. The work-tree commit is a funny kind of merge commit. It consists of two 1 separate commits: the "index" commit (the staging area), and the "work tree" commit. ![]() The thing saved by git stash is what I have taken to calling a "stash bag".
0 Comments
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |