git-stash

I thought they should be basically the same, but when I tried $ git stash show -p stash@{N} and $ git show stash@{N} the latter shows some additional commit information, but the actual diff was much, much shorter. (The former shows about a dozen files, but the latter only one.) So, what exactly is the difference between the two and why are they different? Can I also rely on things like git diff stash@{M} stash@{N} to be correct? torek Stash bags The thing saved by git stash is what I have taken to calling a "stash bag" . It consists of two 1 separate commits: the "index" commit (the staging

We've done something bad. We ran git stash save during a merge conflict, and now we can't restore our work. Things we've tried: git pull -Xours origin master git stash apply --index And: git pull origin master git stash save --keep-index "merge conflicts" git stash apply stash@{1} Please help! The issue seems to be that git stash doesn't save a reference to the branch you were trying to merge in. During a merge, this is stored in a ref named MERGE_HEAD . To fix it and get back to your previous state, you need to find the revision (let's pretend it's d7a9884a380f81b2fbf002442ee9c9eaf34ff68d)

I have a Git alias that expands to: git log --graph --oneline --all --decorate According to man git log there are a couple of suspicious options: --not and --branches ; but I can't make it work properly. How should I edit that to hide the stashes? FYI : as per the accepted question and comment my .gitconfig alias now looks like this: [alias] l = log --branches --remotes --tags --graph --oneline --decorate --notes HEAD Instead of doing --all and then trying to filter out the stashes, don't ever include them in the first place: git log --branches --remotes --tags --graph --oneline --decorate The

I suppose it allows for moving changes from one branch to the next but that's what cherry picking is for and if you're not making a commit of your changes, perhaps you shouldn't be moving them around? I have on occasion applied the wrong stash at the wrong branch, which left me wondering about this question. As mentioned, if you want a “per-branch stash,” you really want a new branch forking off from the existing branch. Also, besides the already mentioned fact that the stash allows you to pull into a branch that you’re working on, it also allows you to switch branches before you have

my git workflow uses rebase a lot. I always fetch upstream changes (the main repo i forked from) and then merge to my branches, and then rebase to remove useless (to me :D) merge commits and tree splits. one thing on this workflow that annoys me is: $ git rebase upstream/master Cannot rebase: You have unstaged changes. Please commit or stash them. $ git stash Saved working directory and index state WIP on cc: abc1234 Merge remote-tracking branch 'upstream/master' into local_branch HEAD is now at abc1234 Merge remote-tracking branch 'upstream/master' into local_branch $ git rebase upstream

I cloned a git repo and then started playing around in its master branch. After a while, I want to ignore the changes I just made (without committing them), and switch to a different branch. However, it stops me from switching because there are uncommitted changes. How do I ignore them without stashing them either? This is what happens: $ git checkout gh-pages error: Your local changes to the following files would be overwritten by checkout: somefile.txt Please, commit your changes or stash them before you can switch branches. Aborting Option 1 git checkout -f gh-pages Option 2 git reset -

A co-worker and I are both working on the master branch at the moment. I have some code in my working tree that I don't want to commit (debugging statements and the like). Now if he commits changes to some of those same files, I can't merge them: $ git merge origin/master Updating 1b8c5c6..eb44c23 error: Entry 'blah.java' not uptodate. Cannot merge. Coming from a subversion background, I'm used to having my working tree automatically merged when I pull changes from the repository and if there are conflicts, I resolve them manually. The quickest way I have found to do this in git is: $ git