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 [1] 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.

Reply via email to