well, thanks for your help. but, in the end i just blew away all my work
and started again from scratch.
i seriously don't understand why it's so hard to do this seemingly simple
thing - bring me up-to-date. i just want it to get the changes, merge them
in and show me the conflicts. i don't know why i have to push my local
changes out of the way first, just so i can bring them in later. if there's
going to be a conflict, why not let 'merge' or 'pull' give it to me, why
make me have to jump through all these extra hoops (stash, stash branch,
reset, cherry-pick, etc...) just to get back to the same place.
i must be missing something, but i just don't see it. what is that SVN is
doing wrong by making this so simple?
On Friday, March 8, 2013 2:51:16 PM UTC-8, Konstantin Khomoutov wrote:
> 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
> > 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
> > 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
For more options, visit https://groups.google.com/groups/opt_out.