Re: master c6f03ed: Fix a problem in url.el without GnuTLS

[Eli Zaretskii <eliz@gnu.org>]

> From: Steinar Bang <sb@dod.no>
> Date: Thu, 18 Dec 2014 21:00:00 +0100
> 
> >   cd ../trunk # another clone
> >   git checkout master
> >   git pull
> >   git merge origin/emacs-24
> 
> What I would do here, is:
>  git merge --no-ff --no-commit origin/emacs-24
> 
> Then I would inspect the diffs in magit, fix any conflicts, and stage
> the conflict-fixed files, revert the changes that shouldn't be there
> (typically version-related stuff, and this is mostly taken care off on
> the first merge, but it never hurts to check), and then do 'c c' in
> magit to commit the merge.
> 
> >   <test, fix problems, commit>
> >   git push

Not sure how what you suggest is different, in principle.  Why does it
matter if I examine the results of a merge before or after I commit
it?  It's a local commit, and I can always go back if I need to.  But
I see no reason to assume up front I'd need to back up, since we are
talking about a merge from the release branch, not from a development
branch.  So I have all the reasons to believe the merge will be
uneventful, and there will be no conflicts most of the time.  Which
makes all the precautions like --no-ff and --no-commit unnecessary, I
think.