On Fri, Mar 08, 2013 at 01:06:04PM -0800, Piers H wrote: > So, i'm doing the 'stash/pull/pop' dance that git forces me to go through > when pulling changes into a modified working tree, and it has come back > with a whole bunch of '<blah blah> already exists, no checkout', 'could not > restore untracked files from stash'. > > so now i'm screwed and extremely frustrated. > > what am i supposed to do in this situation? how do I get my work out of > jail?
I would take one of these two routes: 1) Create a branch out of your stash entry by using the `git stash branch <branchname> [<stash_entry>]` command. Then merge that new branch using the regular `git merge`. If you don't want merge commit to be recorded, cherry-pick that commit using `git cherry-pick -n <branchname>`. 2) Reset the branch you're working on to its pre-pull state, possibly using `git reset --hard <pre_pull_tip_commit>`, where that pre-pull tip branch commit might be learned from the `git log` output of from inspecting the reflog. After this, try some other way of reconciling your local changes with the upstream's. For instance, consider recording a "work-in-progress" throw-away commit of your local changes and then do "rebasing pull" by using `git pull --rebase` -- after reconciling your WIP commit which Git will try to re-apply onto the pulled in changes during the rebasing phase, you will be able to zap it while keeping the changes it introduces in the work tree by running `git reset HEAD^`. > why does git require all these gymnastics just to do a simple merge? > with SVN it was 1 command, and I never had any issues with it. i don't > understand. Judging from the bits you decided to share with us instead of actual typed commands and the error messages they produced, you saved untracked files to the stash and the chain of commits you pulled brought the same files under Git's control. Now you tried to pop those untracked files from the stash and Git refused to overwrite the same-named files in your work tree because *there* they're now tracked. At this point, you could rightfully ask why Git refuses to just compare files in each such conflicting pair and record a merge conflict for each, if needed. I don't know the answer; on the one hand this, indeed, might be seen as a surprising behaviour, on the other, automatically turning untracked files into tracking might be as well surprising to differently shaped minds. I recall someone appearing here sharing their similar frustration with Git not doing file-level merging when bringing in "upstream" changes, with automatically making untracked files tracked, if the same-named files appear in the upstream's changes. I think the discussion was inconclusive as there are valid arguments against this approach. You could try to search for this thread or just ask on the main Git list  about why they didn't implement this. 1. https://gist.github.com/tfnico/4441562 -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.