At 02:13 -0500 07 Dec 2012, Alex Ogier <alex.ogier@xxxxxxxxx> wrote:
For pull requests that originate outside of patches, a convenient work flow is to have the committer merge with 'git merge --squash' as a matter of course. This way allows all of the advantages of distributed version control while still keeping mainline history a linear sequence of clean patches you can bisect to.
While that would take care of the problem that I mentioned about, bisecting to a commit that doesn't mention a mailing list sequence number I believe it creates more, worse issues.
With that a change set that involved a number of commits would be reduced to a single one, so bisecting to that wouldn't give as much information about the actual change which caused the problem. It also loses the finer-grained information about the changes for other purposes.
Also, this would not be convenient for the submitter of the pull request. If a normal merge is done, it is easy for the submitter (or other people) to determine that the branch was fully merged, since the submitted commits are part of the history. With --squash, if the submitter wants to determine if the changes were merged as-is or if further modifications were done a more thorough examination would need to be done, especially if the merge was done on top of a different commit than where the original branch was based.