Ask HN: How often does Git merge make mistakes? | Hacker News Reader

Ask HN: How often does Git merge make mistakes?

1 pointiceman_w5 comments

I was working on an express app with a friend and git auto merged a file after I ran 'git pull'. There were no merge conflicts, but git added duplicate functions to a file after merge. I spent an hour trying to figure our what the problem was before realizing that git had made a mistake while merging.

I had never seen such a thing before. How often does something like this happen?

View on HN

I've never noticed that before, but it's possible that you both had added functions in different places:

    foo() ... ; original

    bar() ...  ; added by alice
    foo() ...

    foo() ...
    bar() ...  ; added by bob

I haven't tried it, but I could imagine that being seen as separate text additions, and ending up with duplicates if git thinks it needs to merge them:

    bar() ... ; alice
    foo() ... ; original
    bar() ... ; bob

You mentioned using `git pull`, which will actually merge things if it thinks it's necessary -- which can lead to tree differences. In practice, I've found it helpful to NEVER USE `git pull`. Rather, I advise using:

    git checkout master
    git fetch origin
    git merge origin/master --ff-only

This will ensure that git only does "fast-forward" merges, and does not end up accidentally merging things - and keeps 'origin' as the system-of-record for what's been merged.

I recommend

git config --global pull.ff only

instead, then you can use "git pull" without worries. Or,

git pull --ff-only

Anyone wondering what a "fast-forward" merge is? https://sandofsky.com/images/fast_forward.pdf

In the following scenario:

origin: A-B-C local: A-B-D

What is the recommended action? git pull --ff-only will fail, right? So should I be using git pull --rebase?

Yes, ff-only will fail. If C,D are independent and simple, I would go ahead and rebase, otherwise do a proper merge.

Remember you can play a lot with git; if you are not sure how it will turn out, checkout a commit (e.g. git checkout origin/master), create a new throwaway branch (git checkout -b tmp), then you can do rebases, cherry-picks, merges etc., then do "git log tmp" or "git log -p tmp" to see how does the branch look. If you are unhappy, you can always throw it out (git branch -D tmp), it won't affect anything else.

I generally avoid the situation when a branch and origin diverges. The flow I have in my work is: If I need to make a small change (few lines), I pull, do changes, commit and push directly to master; if there are any intervening independent changes, pull --rebase. For anything larger, I create a new branch, and commit there. Once it is ready, I give it to a teammate for code review and do automated build, if everything is OK he merges it to master. Other people generally don't push to my branch, and there is no A-B-C vs A-B-D situation.

If several people work together on the same branch, we coordinate actions face-to-face or via team chat, to avoid conflicts. We pull/push many times a day and the changes are small enough so there are no problems with rebasing in a topic branch. If two people make big conflicting changes to the same branch, it means trouble and we merge or even discard some changes.

Reply on news.ycombinator.com