Re: Understanding a recent commit in emacs-25 branch [ed19f2]

[Eli Zaretskii]

> From: Ingo Lohmar <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> Date: Sun, 03 Apr 2016 18:00:38 +0200
> 
> On Sun, Apr 03 2016 18:40 (+0300), Eli Zaretskii wrote:
> > I think your documentation might be outdated.  Here's what the "git
> > pull" man page I have says:
> >
> >   In Git 1.7.0 or later, to cancel a conflicting merge, use git reset
> >   --merge. Warning: In older versions of Git, running git pull with
> >   uncommitted changes is discouraged: while possible, it leaves you in a
> >   state that may be hard to back out of in the case of a conflict.
> >
> >   If any of the remote changes overlap with local uncommitted changes,
> >   the merge will be automatically cancelled and the work tree
> >   untouched. It is generally best to get any local changes in working
> >   order before pulling or stash them away with git-stash(1).
> >
> > This is with Git 2.8.0.
> >
> > IOW, for a recent enough Git, they _recommend_ stashing, but no longer
> > _warn_ about merging in this situation.  Which is exactly my
> > experience.
> 
> For the sake of completeness, my 'git merge' man page for 2.8.0.rc3 says
> (in the DESCRIPTION section):
> 
>        Warning: Running git merge with non-trivial uncommitted changes
>        is discouraged: while possible, it may leave you in a state that
>        is hard to back out of in the case of a conflict.

But we were talking about "git pull", not about merge.

> > I agree that it's preferable to have a clean repo, but in practice it
> > doesn't always work to have it.  Being able to pull when you have
> > uncommitted changes is an important feature; a VCS that doesn't
> > support it is IMO severely broken, because it will get in the way.
> 
> We'll just have to disagree about the "severely broken" part.

Yes, let's do that.