Update: Exclude reverted commits (fixes #3)

btmills commented 8 years ago

When generating changelogs or calculating new versions, reverted commits are ignored. For example:

* abcd123 Docs: Update something in the docs (githubhandle)
* a1b2c3d Revert "Breaking: A breaking change (fixes #1234)" (Committer Name)
* 321dcba Fix: Fix a bug (fixes #4321) (Abc D. Efg)
* 9876543 Revert "New: Add cool new feature (fixes #42)" (Tina Tester)
* abcdef0 Breaking: A breaking change (fixes #1234) (Cool Committer)
* 1234abc Revert "New: From a previous release (fixes #1234)" (Foo Bar)
* 1234567 New: Add cool new feature (fixes #42) (Toby Testing)

Will become:

* abcd123 Docs: Update something in the docs (githubhandle)
* 321dcba Fix: Fix a bug (fixes #4321) (Abc D. Efg)

And the new version will be a patch bump.

calculateReleaseFromGitLogs is only called from calculateReleaseInfo, so we can safely assume the logs are in the format --pretty=format:"* %h %s (%an)" as specified in calculateReleaseInfo. Though calculateReleaseFromGitLogs is included in module.exports, it is marked as @private, so I didn't label this as a breaking change.

ilyavolodin commented 8 years ago

Nice! That was quick! I'll let @nzakas take a look at it before merging. He knows the code best.

btmills commented 8 years ago

Updated. As long revert commits follow the default format of This reverts commit c9c34ea7ecc13d1f90e728c0cccb97bdf96aa5a6., then the reverted commits will be excluded.

btmills commented 8 years ago

This now only excludes reverts from the changelog if the revert commit and the commit it reverts are both included within the release. Reversions of commits in previous releases are included in the changelog, but they are not included as part of the automatic version calculation.

Two remaining caveats that I see:

It requires that revert commits have a line in their body of the form This reverts commit c9c34ea7ecc13d1f90e728c0cccb97bdf96aa5a6.. As this is the default message created by both GitHub and the Git CLI, that shouldn't be an issue unless somebody gets fancy. I don't know that there's an automatic solution to this.
The changelog format currently uses abbreviated 7-character shas. I did some digging, and some rough math says the entire 2.0 changelog from alpha-1 to final would have a 0.058% change of a sha collision, so I'm not too concerned about that. The solution would be to use full shas and some git magic to abbreviate when we just get to the changelog, but I don't think this is necessary.

nzakas commented 8 years ago

Lgtm. I think the caveats are fine.

eslint / eslint-release

Update: Exclude reverted commits (fixes #3) #4