Thanks for working on this! I will give it a look.

Works good for me anyway :)

This produced a lot better (but not perfect) results for me. If it doesn't break existing functionality I'd urge you to merge it.

@tkurki Thanks for trying this out and for the feedback. Curious - what were the not perfect results for you?

Don't think this will breaks something.

At least SignalK/signalk-server#138 is still missing from the result of github-changes -o signalk -r signalk-server-node -a --only-pulls --use-commit-body.

Whats the commit message of the squash?

Have an idea - Lets put this behind a flag --squash-and-merge and put in the description that it's experimental (and what the signature of the commit message needs to include for it to get picked up).

I'm happy to start adding support for it, but because it does miss things I'm a little hesitant to have it enabled on by default.

If you can update with that I'll gladly pull it in :)

Once it's no longer experimental we can update the description.

What do you think?

This one is testing for (#123), but of course it's system dependent (eg github)

Actually now that I reran the version off npm with --only-pulls --use-commit-body --data=pulls I got a result that LGTM. I had overlooked --data=pulls, it being deprecated, and --only-pulls does not do the same thing.

@tkurki given that the --data is deprecated do one of the other options work? maybe --only-merges?

Would like to not support --data anymore.

Well, my vote goes for not removing --data=pulls until you have equivalent functionality available somehow. I'm perfectly happy with the results.

Don't know about the other options.

https://github.com/lalitkapoor/github-changes/blob/master/bin/index.js#L513

@tkurki nice! I had forgotten that --data=pulls uses the github pull request api and not the commit api. That will actually catch all the pull requests :) regardless of the merge strategy. The one thing it won't be able to do though is give attribution to multiple committers, if there were any in that pull request. I think this is an acceptable tradeoff though.

@304NotModified Your solution works for the case when --data=commits (the default), but depends on a (#123) signature in the squash commit message (which is what it defaults to in github). So, I'd like to merge your pull request in too. Do you mind adding a note in your pull request to the readme for how this library handles the squash and merge strategy?

Thank you both for looking into this and debugging this!

Do you mind adding a note in your pull request to the readme for how this library handles the squash and merge strategy?

Sure, but dunno where to add it. It's not "Installation" or "Example usage". Maybe adding a FAQ to the wiki is a better idea?

@304NotModified I think at the bottom of the readme we can start a FAQ section and this can be only thing in it for now.

isn't the wiki a better place for it?

@304NotModified I think since there isn't a lot of content and I'd like for the user to get that information as easily and quickly as possible the Readme will do just fine.

I'm a fan of adding to the Readme till it no longer makes sense.

I've added the FAQ. Please merge.