With the rise in popularity of dependency management bots and other non-human commit-generating entities, commit logs can get very noisy relative to the typical experience in the pre "rise of the bots" era.
It would be nice to have an option for filtering these types of commits out of the list, particularly in the /compare/X...Y UI.
There鈥檚 a problem with including this feature: it鈥檚 a very minor feature and might cause problems (i.e. hiding commits some people might not want to hide), including false positive and thus constant tweaking of the selector.
It's nice to remove noise, but not sure if this is a good idea. What if a rogue bot commits something bad to your repo and we hide that commit.
including false positive and thus constant tweaking of the selector.
Don't all bot usernames end with [bot], like sindresorhus[bot]?
Don't all bot usernames end with
[bot], likesindresorhus[bot]?
false positives
@bfred-it That's just a bot using a normal user account. I don't think we should care about that. It's good enough if it just handles proper [bot] accounts.
That's just a bot
Where are you seeing that? What I'm saying is that there might be usernames ending in -bot and a blanket bot$ selector would ghost all those commits.
We can make an API call to _maybe_ ask what users are bots but what you said in your first comment still stands.
Where are you seeing that?
Look for renovate[bot] here: https://github.com/typed-ember/ember-cli-typescript/compare/v2.0.0-beta.3...v2.0.0-rc.1 And greenkeeper[bot] here: https://github.com/lukechilds/cacheable-request/commits/master It seems GitHub adds [bot] to bot usernames.
I was referring to https://github.com/Sobot, a false positive, a real user
Oh, I thought you meant @sobot was I bot. I didn't actually look at the user profile. I still don't understand what the problem is though. Real bots end with [bot]. We only check for that. What is the issue?
There鈥檚 a problem with including this feature: it鈥檚 a very minor feature and might cause problems (i.e. hiding commits some people might not want to hide), including false positive and thus constant tweaking of the selector.
My thinking was that this filter would default to "off". I definitely agree that starting to filter stuff without telling anyone, or requiring that they "opt in" is a bad idea.
RE: concerns around false positives, there's a knowable and relatively small set of bots that produce this kind of noise
Could we not just have a hardcoded list of "noisy bots"?
I wouldn't necessarily want to remove _all_ bots, since there may be some whose contribution to changelogs is far more meaningful (i.e., auto-fixing a security vulnerability or something)
Whitelist sounds good too.
Could these commits be faded out like we do we merge commits? Safer.
Sounds like all our discussion was for nothing 馃槄
Bots have /marketplace/ or /apps in the URL, which makes it very easy to filter out. Example of noisy commit list: https://github.com/OctoLinker/OctoLinker/commits/master 馃あ
Could these commits be faded out like we do we merge commits? Safer.

Something looks like this? Cool 馃榿
But I'd also like if we can merge serial bot commits into one and collapse them, make the page cleaner and easier to scroll through. Most of us merge several bot PRs at the same time so this happens a lot.
Yes please, also in PR/Issue lists
Most helpful comment
Whitelist sounds good too.
Could these commits be faded out like we do we merge commits? Safer.