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

[Eli Zaretskii <eliz@gnu.org>]

> From: Ingo Lohmar <i.lohmar@gmail.com>
> Cc: acm@muc.de, emacs-devel@gnu.org, kaushal.modi@gmail.com
> Date: Sun, 03 Apr 2016 17:23:03 +0200
> 
> On Sun, Apr 03 2016 18:01 (+0300), Eli Zaretskii wrote:
> 
> >> From: Ingo Lohmar <i.lohmar@gmail.com>
> >> Date: Sun, 03 Apr 2016 14:30:27 +0200
> >> Cc: Emacs developers <emacs-devel@gnu.org>,
> >> 	Kaushal Modi <kaushal.modi@gmail.com>
> >> 
> >> Single caveat: Do NOT start a merge when you have uncommited changes.
> >> If you want, do 'git stash' first to recover them later.
> >
> > I disagree with this caveat.  There's no reason to frighten people
> > like that, as doing such merges will work most of the time.
> >
> 
> This is not about frightening people; to reiterate, this is a prominent
> warning on the git merge man page --- I will not tell people it's ok
> when the official documentation discourages it.

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.

> Also, in my opinion it is conceptually a bad practice to start git
> operations that affect the commit graph (such as merge) from an
> unclean state.

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.

> >> In this case, you have to learn about rebase, as in 'git rebase
> >> origin/master'.
> >
> > "git rebase" is a bad idea when merging a long-lived feature branch,
> > so please don't advise this to users who are evidently not Git
> > experts.
> 
> It is my understanding (and I made it clear that it was partly
> guesswork) that Alan asked precisely for that functionality.  I am not
> sufficiently patronizing to tell intelligent people they are not ready
> for something when they explicitly ask for it. :)

You may wish re-reading some of Alan's past messages about his
adventures with Git, to get a better idea about that.