And I'm not cherry-picking... I usually see much, much worse git logs than this from merge-commit users. In fact, if I scroll down, this is what it looks like:
Edit: For a point of comparison, here's one of my projects using atomic commits and rebases:
My projects also have a linear progression. They look like...
* -- Bugfix
* -- Feature B
| \
| * -- Implement some other logical part of feature B
| * -- Implement first logical part feature B
| /
* -- Feature Agit log --first-parent
With that switch and writing correct merge-commit messages you get the best of both approaches.
That doesn't mean using merge-commits is wrong, that means people write bad commit messages, which you already complained about.
I fear you may be terribly misunderstanding the point of atomic commits and readable commit messages. Everything within a merge commit will still come up during a bisect, for example. If the commits are non-atomic and/or they are badly written, that is still an issue.
--first-parent hides the problem, and adds a new one. I'm not sure what your thinking is. Once again, what's more readable to you of all the screenshots I linked?
#!/bin/bash
bad=$(git rev-parse "$1")
good=$(git rev-parse "${@:2}")
git bisect start "$bad" $good
filter=$(echo "$good" | sed 's/^/^/' | cat <(echo "$bad") - | xargs)
comm -13 \
<(git rev-list --first-parent $filter | sort) \
<(git rev-list $filter | sort) \
| xargs git bisect skip
For anyone unfamiliar with git extension scripts: You should be able to put it in an executable (`chmod +x`) file (say `git-bisect-branch`) in your $PATH to make it usable (`git bisect-branch $bad $good...`).
I suspect that if merge-commits hadnt been the default on github since forever, it wouldnt have so many proponents.
Do you have buy in from other team members for this?
Also what do you do if master needs to be merged back into develop? Do you really rebase develop and make everyone fiddle with all their feature branches?
You can see this in action here: