The first example does not rebase first...

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 A

I am curious as to why this is downvoted? This can be a valid answer to the parent's concern.

Let me fix this for you...

git log --first-parent

With that switch and writing correct merge-commit messages you get the best of both approaches.

"And correct merge-commit messages" -- I've NEVER seen those. In 99.99999% of projects, this is what you'll get:

https://imgur.com/a/4f6Hw2w

You're moving goalposts. Yes almost nobody changes the default merge-commit message. But that's because, like you, they don't know about --first-parent (or they just don't care about commit history)

That doesn't mean using merge-commits is wrong, that means people write bad commit messages, which you already complained about.

… am I moving goalposts? I do know about --first-parent and it is not intended to be a feature to make git logs readable. It gets rid of nearly the entire git history. At this point, you might as well simply go to the github page and look at merged PRs; that will actually get you something readable.

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?

Not to argue in either direction, but I think you should be able to "fix" the bisect problem with a script like this:

  #!/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

I haven't tested it all too thoroughly, but from what `git bisect view` tells me, this seems to work like a `git bisect --first-parent`. I'm wondering why there is no such option...

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

Good branch names end up in the default commit by default...

You'd want to use a repo that only allows fast-forward and rebase everything that would be a merge. We use Gerrit for that.

Yup, that's what I'm arguing in favour of. I systematically disable merge commits on every repo I manage.

I suspect that if merge-commits hadnt been the default on github since forever, it wouldnt have so many proponents.

> I systematically disable merge commits on every repo I manage.

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?

There is no develop, master is continuously deployed. Users can create feature branches and PR them but there is just no merge commit, they are pulled in fast-forward. In projects where I need stable releases, I create stable/1.2.x type branches off of master at a point in time. I cherry-pick commits onto it after the first release if there are subsequent ones.

You can see this in action here:

https://github.com/dj-stripe/dj-stripe/commits/master

https://github.com/dj-stripe/dj-stripe/commits/stable/1.2

Though fast forward merge commits (where the referenced tree is the same as referenced by the second parent) can be useful because they provide a way for you to group related commits for a feature together (git log merge_commit^..merge_commit^2). There are features that require more than a single commit to implement.

Let me this fix for you too: don’t merge master into featur branches. What kind of insanity is that?