rotary-genomics / rotary

Assembly/annotation workflow for Nanopore-based microbial genome data containing circular DNA elements
BSD 3-Clause "New" or "Revised" License
2 stars 1 forks source link

Improve multi sample pathing #73

Closed LeeBergstrand closed 10 months ago

LeeBergstrand commented 10 months ago
LeeBergstrand commented 10 months ago

Passes --dry-run but is still testing with real data.

LeeBergstrand commented 10 months ago

Nice work -- this looks good to me. I'm working off-site and don't have access to the server for end-to-end testing, but shall we go ahead and merge this into add-multi-sample and then do end-to-end testing there?

Update: there were no merge conflicts, so I created a PR of my short read QC work into this branch at #75 . The comment below is no longer relevant: One more thought -- I made a new branch from this branch yesterday for short read QC work. What is the best way to avoid merge conflicts between my short read QC branch and the other branches down the road, given that some additional work has been done on this multi sample pathing branch? Would it be best to merge the last ~24 hours' changes from this branch into my short read QC branch and deal with any merge conflicts there, for example, rather than wait to deal with merge conflicts later? This would let the short read QC branch merge directly into add-muti-sample or develop later on without much trouble. Thanks!

So, the general best practice is to push and merge as often as possible so your branches stay similar. However, there are techniques like git rebase (https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase) that can be used to pluck branches and move their start points around. Rebases can only be used locally as they rewrite the history.

LeeBergstrand commented 10 months ago

Nice work -- this looks good to me. I'm working off-site and don't have access to the server for end-to-end testing, but shall we go ahead and merge this into add-multi-sample and then do end-to-end testing there? Update: there were no merge conflicts, so I created a PR of my short read QC work into this branch at #75 . The comment below is no longer relevant: One more thought -- I made a new branch from this branch yesterday for short read QC work. What is the best way to avoid merge conflicts between my short read QC branch and the other branches down the road, given that some additional work has been done on this multi sample pathing branch? Would it be best to merge the last ~24 hours' changes from this branch into my short read QC branch and deal with any merge conflicts there, for example, rather than wait to deal with merge conflicts later? This would let the short read QC branch merge directly into add-muti-sample or develop later on without much trouble. Thanks!

So, the general best practice is to push and merge as often as possible so your branches stay similar. However, there are techniques like git rebase (https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase) that can be used to pluck branches and move their start points around. Rebases can only be used locally as they rewrite the history.

Also, I sometimes pull the parent branch into my feature branch every once in a while to stay updated.

jmtsuji commented 10 months ago

@LeeBergstrand Got it -- helpful tips! Thank you for merging changes from develop into the short read QC branch in #77