CODEWITHSUNDEEP
gitgit-stash
Key Lay
Key Lay

Reputation: 366

How do I tell what branch I was on when I stashed changes?

I'm aware of git stash show -p stash@{0} giving the log of changes saved into that stash entry, but I'd like to know what branch I was on when I made those changes. This would be very helpful for a number of scenarios:

Upvotes: 3

Views: 594

Answers (2)

torek
torek

Reputation: 487875

(Ideally this should be a comment, but it's way too big and needs too much formatting...)

Note that the branch name (stored as part of the default message) is just the name at the time of the stash. If you have an old stash that you have been ignoring for a while, it's possible that the branch name has moved. For instance:

$ git checkout -b hack
...
$ git stash   # creates "WIP on hack"
...
$ git branch -D hack # delete hack branch
...
$ git checkout -b hack
...
$ git stash list

The "WIP on hack" you'll see in the list is the old hack branch, not the new one.

The actual stash reference—the thing stored in stash@{4} or whatever the number is—points to a specific commit (the special peculiar merge commit that git stash saves, which I call a "stash bag"). That commit has a parent commit, which has another parent, and so on; this chain of parents forms the actual branch structure within the commit graph that git keeps. The branch name is just that: merely a name, something you can change at whim, or delete with git branch -D hack for instance, but the branch structure is permanent, at least as much as any git commit is permanent. (Commits remain in the repository as long as they are "reachable" from some named starting point, such as stash@{4}.)

If, for instance, you have rebased the branch the stash was made on, the stash itself points to the old (un-rebased) branch structure:

                n - n   <-- hack
              /
* - * - * - *           <-- mainline
      \
        o - o           <-- [old hack when stash was made]
            |\
            i-w         <-- stash@{4}

Here, the stash-bag hangs off the last "old" commit o, while branch hack, which was rebased, now points to the last "new" commit n.

You can of course apply or pop the old stash-bag onto the new branch; that's how stashes are meant to work, more or less. Or you can use git stash branch to convert the old stash into a new branch of its own: for instance, if you did:

git stash branch restore-hack stash@{4}

you would get this graph:

                n - n   <-- hack
              /
* - * - * - *           <-- mainline
      \
        o - o           <-- restore-hack

with the index now containing whatever it contained when you did the original git stash, and the work-tree set up the way it was when you did that same git stash. (In other words, the "stash bag" has been unpacked into the index and work-tree.) You can now git add and/or git commit to make more commits on the restored (old) hack branch, now named restore-hack.

If you find yourself with a lot of old saved stashes, you may wish to start doing real commits that are just intended to be reworked later (as Andreas Wederbrand suggested in his answer). I find they tend to be less confusing, myself, and with my need to rebase to pick up "upstream" changes, they just automatically rebase.

Upvotes: 1

Andreas Wederbrand
Andreas Wederbrand

Reputation: 39951

That is shown with git stash list. In this example "on dude" shows branch dude and "on master" shows branch master.

$ git stash list
stash@{0}: WIP on dude: 7eb87fe initial
stash@{1}: WIP on master: 7eb87fe initial

Also, it sounds like you are stashing when you abandon work temporarily. I have another workflow that I think is superior to stashing, I commit it and then reset it. That way the change is on the branch and if I ever abandon that branch the related code is discarded as well. 

# do some work on dev
git co -b dev
# temporarily abandon it
git commit -a -m'commit instead of stash'
# do other work on master
git co master
# lets resume the old work
git co dev
# un stash
git reset HEAD^

Upvotes: 7

Related Questions