[rbehrends]

> Moreover, if you can rebase -i on top of master you can turn the merge into a fast-forward rather than an actual merge. A more linear history with fewer merges is much easier to bisect as well as to read, generally.

Au contraire, rebase can break bisect by creating commits that were never actually tested or compiled. And if your bisection algorithm cannot handle merges, then that's a problem with a bad bisection algorithm.

Nor does it make history more readable; it makes history more readable in the same sense that inlining all procedures makes a program more readable (i.e. not really).

Merge commits are an abstraction mechanism. You can view a branch's history as a purely linear history (git log --first-parent) of normal and merge commits, where merge commits represent the merged branches (and where the commit message should summarize the branch changes properly). You can then unfold merge commits and view the branches they represent in such a quasi-linear fashion, too. Repeat as needed.

This can also guide a bisection algorithm (bisect along git log --first-parent, descending down the merge hierarchy as necessary) and is generally more readable if presented properly (that Git doesn't have a tool other than git log --first-parent for this is a different story). Conversely, a fully linearized history is longer and lacks any structure (as I said, it's like manually inlining all procedures in a piece of code).

[jsolson]

> Au contraire, rebase can break bisect by creating commits that were never actually tested or compiled. And if your bisection algorithm cannot handle merges, then that's a problem with a bad bisection algorithm.

This is only true if you allow commits that haven't individually passed your CI suite to be pushed. That's insane.

> Nor does it make history more readable; it makes history more readable in the same sense that inlining all procedures makes a program more readable (i.e. not really).

Working at an organization (Google) that for the most part doesn't use branches and where other merges are impossible (every file must have previously been resolved against whatever is at HEAD prior to submitting), I respectfully disagree[0]. A linear history of individually reviewed and validated changes is MUCH easier to deal with than the regularly branched/merged history of my previous gig (which did use git, along with pre-push change review for each change).

> Merge commits are an abstraction mechanism. You can view a branch's history as a purely linear history (git log --first-parent) of normal and merge commits, where merge commits represent the merged branches (and where the commit message should summarize the branch changes properly). You can then unfold merge commits and view the branches they represent in such a quasi-linear fashion, too. Repeat as needed.

They're a leaky abstraction, though. Unless you mutate published history (which I do think is insane) it's inevitable that your nice bundle of merged changes will one day be incomplete: additional changes to make the bundle actually function as intended will be required. These will end up detached from it as some other commit series on HEAD or merged into HEAD. I find it far easier to tie together a series of changes via things like issue tags in the commit than expecting a merge commit to properly bundle things up.

[0]: Mind you, Google also for the most part does not use git -- we do our own thing, and with that history is necessarily linear, but I've found I really do prefer it that way. See: http://www.wired.com/2015/09/google-2-billion-lines-codeand-...

[rbehrends]

> This is only true if you allow commits that haven't individually passed your CI suite to be pushed. That's insane.

It's also pretty common in open source projects (due to limited CI resources or other reasons). I also note that this is not the only problem: the problem is that these commits never existed in the wild. This can also lead to subtle problems that CI simply can't catch.

> Working at an organization (Google) that for the most part doesn't use branches and where other merges are impossible (every file must have previously been resolved against whatever is at HEAD prior to submitting), I respectfully disagree[0]. A linear history of individually reviewed and validated changes is MUCH easier to deal with than the regularly branched/merged history of my previous gig (which did use git, along with pre-push change review for each change).

Your problem here is that Git does not have a good way of displaying structured history and just throws the raw DAG or a topologically or chronologically sorted list at the user; lack of named branches means that you're largely looking at an anonymous soup of objects with no tools to filter them. Contrast with Bazaar's hierarchical logs (augmented with branch nicknames), for example, if you want to make a serious argument.

> They're a leaky abstraction, though. Unless you mutate published history (which I do think is insane)

Published mutable history is not per se insane. Please familiarize yourself with Darcs/Pijul/Mercurial's changeset evolution. Note that I am not saying this is necessarily a good idea, it's just not per se insane. Not all projects have the same requirements/workflow/number of contributors/etc.

> it's inevitable that your nice bundle of merged changes will one day be incomplete: additional changes to make the bundle actually function as intended will be required. These will end up detached from it as some other commit series on HEAD or merged into HEAD.

Note that when I say that this is an abstraction mechanism, it's not the only abstraction mechanism. This, again, is a Git problem [1], not a VCS problem. This is, for example, where named branches come into play; see in particular Fossil's tagging mechanism (which has little to do with Git-style tags) or Veracity's stamps.

[1] Git is a solid workhorse for a DVCS, but it is a very basic version control system, sort of the lowest common denominator in the DVCS world. This makes it a poor basis for arguments as to what can be done in a VCS.