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

> 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.

Reply via email to