W3C home > Mailing lists > Public > public-html-media@w3.org > September 2015

Please squash all commits before merging pull requests

From: David Dorwin <ddorwin@google.com>
Date: Fri, 4 Sep 2015 11:13:27 -0700
Message-ID: <CAHD2rsgcHYzPPQ5fm8Om9b7XMfpHE83sB2-jLGkkA-i-dw93OA@mail.gmail.com>
To: "public-html-media@w3.org" <public-html-media@w3.org>, Matt Wolenetz <wolenetz@google.com>, Mark Watson <watsonm@netflix.com>, "Jerry Smith (WINDOWS)" <jdsmith@microsoft.com>
GitHub pull requests are a great tool, but they can also complicate the
commit log. What once was a relatively linear commit history can become a
mess of parallel "branches" over long periods of time. This is most obvious
in tools like gitk, but the GitHub history is also confusing because the
commits from a single pull request may be scattered throughout the commit
log.

This is most important for merges from upstream into the pull request as
the author keeps the branch up-to-date. These merges appear as commits in
the history once the pull request is merged. However, updates based on
review feedback or fixing spelling also appear as separate commits, which
can make it hard to see exactly what was committed.

See http://programmers.stackexchange.com/a/263172 for additional
explanation.


I propose:

To minimize the impact, please squash all commits in a pull request into a
single commit before merging it. Committers (editors) should make sure
commits have been squashed before merging their own or others' pull
requests.

There will be exceptions. For example, sometimes a pull request might have
multiple distinct actions (i.e. do something then rename a variable), in
which case the branch might be squashed into two commits.


Details:
The squashing happens in the branch and updates the pull request before it
is merged. Thus, you should be able to view the results in GitHub before
merging into the mainline. Most of the magic happens with "git rebase -i
<base-commit>" on your local repository. Be sure to pick the right
base-commit for <base-commit>. (For merges, this appears to be the master
branch.) Then, you need to (force) push your changes to GitHub.

The one drawback is that the previous commits are wiped from the commit
history for your branch. That means the review history and comments are no
longer browsable (as far as I can tell). They appear to still be available
if you have the URLs, though. Thus, if you want to maintain history, it
might make sense to create a new branch and/or pull request with the
squashed commit.

Note: You can also fix commit messages using the "reword" feature of "git
rebase -i". For example, if you forgot to refer to the issue number.

References:

   - http://programmers.stackexchange.com/a/263172
   -
   https://github.com/ginatrapani/todo.txt-android/wiki/Squash-All-Commits-Related-to-a-Single-Issue-into-a-Single-Commit
   - https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request
   -
   http://eli.thegreenplace.net/2014/02/19/squashing-github-pull-requests-into-a-single-commit
Received on Friday, 4 September 2015 18:14:15 UTC

This archive was generated by hypermail 2.3.1 : Friday, 4 September 2015 18:14:15 UTC