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

[Artur Malabarba]

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