Re: [git-users] HELP! "stash pop" is failing and I can't get my work out
On Sat, 9 Mar 2013 09:44:34 -0800 Piers Haken wrote: > >> i must be missing something, but i just don't see it. what is that > >> SVN is doing wrong by making this so simple? > > > > Let's cite the `git merge` manual: > > > > Warning: Running git merge with uncommitted changes is discouraged: > > while possible, it leaves you in a state that is hard to back out > > of in the case of a conflict. > > > > So, if you don't want to take this warning or think it does not > > apply to you, just `git pull` to a dirty tree. > > Ok, I remember reading that. But it's not helpful because its not > really possible. > > Firstly, if you just do a 'git pull' you're likely to run into > conflicts which require an alternative route. At that point I > begrudgingly try a 'stash/pull/pop' but that doesn't work either in > general due to conflicts with untracked files, so then I have to do > whatever voodoo you suggested above. I think you contradict yourself here. "The Subversion way" to pull upstream changes in is to run `svn up` and have conflicts in the work tree. You lamented the apparent lack of something like this in Git, but now you tell that it's not okay to just pull the changes in and have conflicts. In Subversion, if you want to `svn up` and have no conflicts *at that stage* you have to run `svn diff` to save a patch, revert everything in the work tree to match BASE and then run `svn up` -- this will guarantee a clean update but you then you will have to deal with the conflicts when applying the generated patch file with `patch` (or `svn patch` in later versions). Can't you see that Git's `git stash save` + `git stash pop` is roughly the same machinery as `svn diff` + `svn patch` w.r.t. local changes are in Subversion? Apparently the real problem you're facing is handling of untracked files: if you save untracked files when doing `git stash save` (note that by default untracked files are not stashed), and later try to apply them, `git stash` refuses to "apply" untracked files from the stash if the same-named files exist in the work tree -- in an attempt to not clobber their contents. The same happens when you're trying to pull while having untracked files in the work tree: if the upstream commit which is about to be merged with the HEAD contain files clashing with untracked files in your work tree, the merge will abort. Note that if there's no untracked files in both cases, you will have normal merge -- possibly with conflicts, but this merge will at least happen. > My question is this: given that I have local changes, and given that > the branch I have has changes that conflict in all those ways, what's > the simplest possible way for me to merge those changes, conflicts > and all, into my tree? Let's recap first. Both pulling upstream changes into a dirty tree and trying to apply a stash entry which has untracked files results in a merge, and in both cases Git refuses to carry out merging if it sees untracked files clashing with other files. Hence "the voodoo", as you called it, boils down to one simple thing: somehow frame out untracked files before attempting a merge. Basically there are two possibilities: 1) move them someplace by hand, then merge, then move them back by hand, deciding how they should integrate into the changed picture; 2) make them tracked by `git add`-ing them first, and then proceed with the merge -- since they will be tracked, normal merge semantics will be applied to them. You claim that Git behaves badly with regard to handling untracked files in these cases. I can only say that it tries to preserve everything you have in your work tree and which might get lost. If you're able to formulate how it should behave in cases like yours in a sensible manner, feel free to share your ideas on the main Git list (see below). > And if that's not a single command, might I suggest that it should be? Sure, but unfortunately not on this list: it's dedicated to helping newbie users solve their problems. The Git developers may be contacted using the main Git list -- see 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.
Re: [git-users] HELP! "stash pop" is failing and I can't get my work out
On Mar 9, 2013, at 3:02 AM, Konstantin Khomoutov wrote: > On Fri, Mar 08, 2013 at 06:03:34PM -0800, Piers H wrote: >> i must be missing something, but i just don't see it. what is that SVN is >> doing wrong by making this so simple? > > Let's cite the `git merge` manual: > > Warning: Running git merge with uncommitted changes is discouraged: > while possible, it leaves you in a state that is hard to back out of in > the case of a conflict. > > So, if you don't want to take this warning or think it does not apply > to you, just `git pull` to a dirty tree. Ok, I remember reading that. But it's not helpful because its not really possible. Firstly, if you just do a 'git pull' you're likely to run into conflicts which require an alternative route. At that point I begrudgingly try a 'stash/pull/pop' but that doesn't work either in general due to conflicts with untracked files, so then I have to do whatever voodoo you suggested above. My question is this: given that I have local changes, and given that the branch I have has changes that conflict in all those ways, what's the simplest possible way for me to merge those changes, conflicts and all, into my tree? And if that's not a single command, might I suggest that it should be? -- 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.
Re: [git-users] HELP! "stash pop" is failing and I can't get my work out
From: "Konstantin Khomoutov" To: Sent: Saturday, March 09, 2013 11:02 AM Subject: Re: [git-users] HELP! "stash pop" is failing and I can't get my work out On Fri, Mar 08, 2013 at 06:03:34PM -0800, Piers H wrote: [...] 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? Let's cite the `git merge` manual: Warning: Running git merge with uncommitted changes is discouraged: while possible, it leaves you in a state that is hard to back out of in the case of a conflict. So, if you don't want to take this warning or think it does not apply to you, just `git pull` to a dirty tree. Looks like it might be useful setting one of the config advice.* :- " commitBeforeMerge Advice shown when git-merge(1) refuses to merge to avoid overwriting local changes." may be relevant here. I haven't checked what it says (which may be the existing OP message), but I'm hoping it maybe that it 'stop's before starting the dirty merge'. There are also a lot of merge.* config flags available as well. One of which may also be able to cause the 'stop's before starting the dirty merge'. It would surprise me if there wasn't, but then Git's full of surprises. At the moment my git-merge man page, under 'pre-merge checks', says: "git pull and git merge will stop without doing anything when local uncommitted changes overlap with files that git pull/git merge may need to update." So I'm not quite sure how that fit's with the original problem report. Philip -- 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.
Re: [git-users] HELP! "stash pop" is failing and I can't get my work out
On Fri, Mar 08, 2013 at 06:03:34PM -0800, Piers H wrote: [...] > 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? Let's cite the `git merge` manual: Warning: Running git merge with uncommitted changes is discouraged: while possible, it leaves you in a state that is hard to back out of in the case of a conflict. So, if you don't want to take this warning or think it does not apply to you, just `git pull` to a dirty tree. -- 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.
Re: [git-users] HELP! "stash pop" is failing and I can't get my work out
well, thanks for your help. but, in the end i just blew away all my work and started again from scratch. not happy. 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 > through > > when pulling changes into a modified working tree, and it has come back > > with a whole bunch of ' 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 []` 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 `. > > 2) Reset the branch you're working on to its pre-pull state, >possibly using `git reset --hard `, >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.
Re: [git-users] HELP! "stash pop" is failing and I can't get my work out
On Sat, Mar 09, 2013 at 02:51:16AM +0400, Konstantin Khomoutov wrote: [...] > 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. Found it: http://groups.google.com/group/git-users/browse_thread/thread/2e654a307b580973 -- 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.
Re: [git-users] HELP! "stash pop" is failing and I can't get my work out
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 ' 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 []` 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 `. 2) Reset the branch you're working on to its pre-pull state, possibly using `git reset --hard `, 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.
[git-users] HELP! "stash pop" is failing and I can't get my work out
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 ' 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? 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. -- 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.
