[MRG] ENH: Added kwargs options to plot_spikes_hist

[samadpls]

Closes #186

• Enhance plot_spikes_hist() function with kwargs options

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.67%. Comparing base (d28ddb7) to head (e28e70d).

❗ Current head e28e70d differs from pull request most recent head 2d581ff. Consider uploading reports for the commit 2d581ff to get more accurate results

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #732   +/-   ##
=======================================
  Coverage   92.67%   92.67%           
=======================================
  Files          27       27           
  Lines        4928     4928           
=======================================
  Hits         4567     4567           
  Misses        361      361           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[rythorpe]

Looks good @samadpls. You'll need to update the API section of whats_new.rst as well. Any other concerns/suggestions here @jasmainak @ntolley?

[jasmainak]

You'll also need to update the tests @samadpls

but your priority at this point should be finalizing the GSoC proposal. Are you on the same page with @ntolley and @rythorpe ?

[samadpls]

You'll also need to update the tests @samadpls

but your priority at this point should be finalizing the GSoC proposal. Are you on the same page with @ntolley and @rythorpe ?

Sure, I'll update the test too.
Yes, @ntolley has given approval to upload it, and I'll do that today.

[rythorpe]

It looks like you need to update your master branch and then do an interactive rebase to resolve conflicts. Have you done something like this before @samadpls?

[samadpls]

It looks like you need to update your master branch and then do an interactive rebase to resolve conflicts. Have you done something like this before @samadpls?

Sure, Yes, I've done that before.

[rythorpe]

Cool, just don't forget to backup your local branch in case things go awry. And please reach out if you run into any issues!

[rythorpe]

FYI @samadpls, it's best practice in this project to rebase your branch onto your updated fork of master rather than merging. Rebasing, though tricky at times, maintains a linear history of everything that was introduced in each commit and allows us to do a rebase + fast-forward merge onto master when the PR is complete.

[jasmainak]

I recommend updating whats_new.rst just before merge because that's a file everyone touches in their pull request. It will reduce likelihood of conflicts. Squashing commits or cherry-picking can also help with a tricky rebase

[jasmainak]

Can you squash your commits and rebase?

[samadpls]

Could you please guide me on performing a rebase and squash task?
Currently, I have been following these steps:
First, I run the command git rebase -i HEAD~7.
Then, I modify the pick commands to squash in the interactive rebase editor, save the changes, and proceed. However, when I attempt to execute git push origin enh/spike-hist --force, nothing seems to happen. I may be mistaken or doing something wrong. Could you assist me with this?

[jasmainak]

That seems like the right process ... you must be missing something, like you are perhaps on the wrong branch or pushing to the wrong remote. Also you have 25 commits to squash here not 7 ... I could also squash and merge for you if that makes your life easier

[samadpls]

I could also squash and merge for you if that makes your life easier

Thank you for your offer. Please proceed with squash and merge for me.

[rythorpe]

@samadpls I think the merge commits are messing you up since git-rebase handles them differently than other commits. You also have multiple nested squash commits which makes things even trickier.

Since you only touch 4 files, I'd recommend backing up your changes, removing all commits from the root of this branch (using reset or interactive rebase), and replicating your work in 1 or a handful of commits. I know this is probably annoying, but it'll be faster than untangling your merge history.

[samadpls]

Thanks a lot for reaching out and suggesting changes, @rythorpe! It worked perfectly. I finally learned how to rebase this way. 😅

[rythorpe]

Looks good @samadpls! In the future you won't necessarily need to squash your commits, but it made sense here to simplify things. Glad you got the rebase figured out.

As soon as you're other PR is merged (I've set it to automerge once the tests pass), you'll need to rebase onto an updated master again since there will be a conflict in whats_new.rst caused by your most recent entry.

[jasmainak]

I often use git commit --amend and force push to keep the commit history clean

[jasmainak]

Thanks @samadpls !