On Sat, 9 Mar 2013 09:44:34 -0800 Piers Haken <pie...@gmail.com> 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.
