Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 28 May 2015 17:24:30 +0100
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: Michael Albinus <michael.albinus@gmx.de>, emacs-devel <emacs-devel@gnu.org>
> Yes, that was the point. If I wrote a commit to fix something that's already
> fixed, that commit is now useless, so I discard it. 

This is a singular situation that happens very rarely, so it's really
more of exception than the rule.

Learning to deal with merge conflicts, OTOH, will teach the user to
cope with a much broader class of problems.

> 1. Reverting a commit only affects code I've just written, so it takes very
> little mental energy. I know what I'm changing with 100% certainty.
> 2. Resolving a merge conflict involves both mine and someone else's code, so
> I'll need to invest some energy to read and interpret that code (might be a
> little or a lot, depending on the code).

If you got a conflict, it means you've modified the same areas as that
someone, so presumably you know enough about that code to deal with
the conflict.

> 3. Even after I've read and interpreted the new remote code, there's always a
> small chance I miss some tiny detail inside a large diff when resolving the
> conflict. (I've introduced bugs this way a couple of times, whereas I've never
> introduced a bug while reverting).

Talking with the persons involved is allowed.  Git doesn't make us
speechless.

> 4. Even when the conflict is simple and I know I can solve it without risk,
> doing the merge will still keep redundant commits in the history. It's not a
> huge deal, but there's no reason to have two commits doing the exact same
> thing. 

Yes, there is a reason: use a routine procedure as frequently as it
fits the bill, and you will become fluent with it and stop being
scared.