It is very easy to create a mess with merge. It's almost always ok when you're working alone, but the moment you have to share, it is much more practical to have linear history. I've seen repositories consisting only of merges, because two developers just pulled and pushed from the central repo. You know, when you pull by default it creates a merge commit if it is not possible to do fast forward, and you can push it, and then everyone on the project will see that commit, and when they pull each of them could potentially create a new commit, and push it and so on.
I find linear history easier to navigate. You don't need anything fancy, just a simple git log will do just fine.
If you use merges on your local repo and you try to rebase your work on some other branch, you're in trouble. That's not an easy job. And it might be possible that you'll be required to rebase.
So, I prefer rebase/fast-forward policy on all my repos. :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It is very easy to create a mess with merge. It's almost always ok when you're working alone, but the moment you have to share, it is much more practical to have linear history. I've seen repositories consisting only of merges, because two developers just pulled and pushed from the central repo. You know, when you pull by default it creates a merge commit if it is not possible to do fast forward, and you can push it, and then everyone on the project will see that commit, and when they pull each of them could potentially create a new commit, and push it and so on.
I find linear history easier to navigate. You don't need anything fancy, just a simple git log will do just fine.
If you use merges on your local repo and you try to rebase your work on some other branch, you're in trouble. That's not an easy job. And it might be possible that you'll be required to rebase.
So, I prefer rebase/fast-forward policy on all my repos. :)