On Mar 8, 1:28pm, Junio C Hamano <gits...@xxxxxxxxx> wrote: > The solution to whatever problem you are trying to solve should not be to > discard one of the most valuable information git keeps track of to avoid > the CVS/(old)SVN mess when performing repeated merges with a branch. Junio, this seems viable precisely because we generally don't perform repeated merges between the same heads. All of our branches right now are feature branches of master, whose short lives end with a single merge back. Thus, merging back as a single patch implementing that single feature is ideal: the branch was only created to implement the feature, so by definition all of its individual commits are intermediary, and once the final feature state is achieved, the incremental steps leading to it are not interesting at all - they're just noise! Why would John care that while implementing feature X, Jill committed her half-state Y so she can go home, or made and fixed typo Z ? In fact, why would Jill care a day, let a lone a couple of months, after X was completed and merged to master? The noisy, needless nature of these commits is further emphasized by the default behavior of commit graph visualizers to display them in full rather than collapse them. We have over 80 developers working on all major operating systems, and using a variety of tools on each. `log --first-parent` is nice, but my developers also use gitk, gitg, gitx, GitExtensions, and TortoiseGit. Finally, we are planning to integrate a few key long-lived branches, for example a 'bleeding_edge' branch that everyone commits to, and gets periodically merged into master by a technical lead. The collapsing behavior a-la `--first-parent` may not always be desirable once we start doing that, but if you turn it off without mandating squashes, master's history becomes a mess of numerous feature-branch merges, with all of their non-informative intermediary commits. Hope that makes sense, .D -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html