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

[Steinar Bang <sb@dod.no>]

>>>>> Eli Zaretskii <eliz@gnu.org>:

> Not sure how what you suggest is different, in principle. 

Not different, just convenient.

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

Yes, of course.  But magit's presentation of a staged, but yet
uncommitted merge, is a very convenient and keyboard-only way of viewing
the merge resuls (a compact representation of new files, for one thing,
compared to a diff), and it's easy to fix conflicts, and revert files
without leaving emacs.

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

Not so much conflicts merging that way, but version number stuff always
show up on the first merge, and sometimes later as well (it's good to
check).  And in emacs' case there has been the ChangeLog stuff (are they
autogenerated and not committed these days?).

> Which makes all the precautions like --no-ff and --no-commit
> unnecessary, I think.

I don't do it merging in to my own branches, but I always give published
merges a final look-over in this way before pushing them (ie. merges
_to_ master and release branches).