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

[Artur Malabarba <bruce.connor.am@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2663 bytes --]

>> As a general tip. Next time you try to pull and find out someone
>> already has already done what you just did, don't resolve the merge
>> conflict. Instead, abort the merge with git merge --abort (this will
>> get you back to the state you had right before the pull), and then
>> locally revert your commit.
>
> I don't see how this advice will be able to keep Michael out of
> trouble next time.  AFAICT, it will just get him in a different
> situation, one that isn't simpler or safer to deal with.  Locally
> reverting commits risks losing them, for example.

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.

The reason I prefer that instead of merging is that it's just easier and
simpler that way (at least to me), mainly because:


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

I'm not saying merge conflicts are the devil, or that they're any reason to
panick. But if I can prevent the conflict by killing a redundant commit,
then that is easier, safer, and cleaner.

However, you're right that a person who is not very familiar with git is
better off not mucking around with things like reset, revert, and rebase.
OTOH, you can always just create a branch wherever you are and use that as
a backup. When I was first learning git, that was the first thing I did
everytime I panicked, and it never failed me.

> OTOH, merge conflicts are nothing to be afraid of, the procedure to
> handle them is simple and straightforward.  Michael (and every one
> else here) should IMO master that simple procedure, instead of
> avoiding it.
>
> In a dVCS, you cannot rely on being able to avoid merges all the time
> anyway.  There are always races with other developers.

Agreed. Merge conflicts are just part of the deal. I was just explaining
how I avoid one specific type of conflict.

[-- Attachment #2: Type: text/html, Size: 3019 bytes --]