search

nuest / ten-simple-rules-dockerfiles

Ten Simple Rules for Writing Dockerfiles for Reproducible Data Science
https://doi.org/10.1371/journal.pcbi.1008316
Creative Commons Attribution 4.0 International
61 stars 15 forks source link

Fix some minor typos and adjust phrasing #63

Closed bdevans closed 4 years ago

bdevans commented 4 years ago

This is a simple and hopefully uncontroversial PR to start with doing as described in the title.

vsoch commented 4 years ago

@bdevans it looks like your commits from #64 are also represented here - is there reason for two equivalent PRs? If you want to do separate (modular) sets of changes you will want to checkout each new branch directly from the current master (and not from the branch you just worked on). Let's confirm that there aren't differences here, and then close this PR in favor of #64.

vsoch commented 4 years ago

And if there are changes, we have two options:

  1. review and merge the PR so that the changes / differences are more stated here
  2. cherry pick the commits from here that aren't represented in #64, close PR here.

Either works for me! It's just hard to review it since most of the changes are in the other PR.

bdevans commented 4 years ago

Hi @vsoch, ah sorry - I meant to submit granular PRs, so should have put these edits in a feature branch but mistakenly made them in master and branched from there so they ended up in PR #64 with the figure. I think this should be safe to close then as all the edits should be in the other PR (#64) too.

vsoch commented 4 years ago

No worries, I've done this too! Let's leave this open until the other is merged, then you can rebase with master here and we can be absolutely sure there aren't any commits here not represented in the other PR. If you are absolutely sure, then yes please go ahead and close.