Update README.md #134
Update README.md #134
Conversation
Co-authored-by: Andrew Kiss <31054815+aekiss@users.noreply.github.com>
| @@ -94,6 +76,7 @@ to | |||
| ```yaml | |||
| runlog: true | |||
| ``` | |||
| We recommend you create your own fork of this repository, and commit your branch to that fork. Otherwise, just committing your branch to a new github repository is a good way to track provenance and history of your work. | |||
There was a problem hiding this comment.
it seems confusing to have this bit at the end of the instructions, rather than at the start - why not say to first create a fork, and then payu clone from that?
There was a problem hiding this comment.
This is how we've written it in other docs and is maybe our 'general' advice - @aidanheerdegen I think you have thoughts on this ?
There was a problem hiding this comment.
Also is creating a fork messy due to branching ? e.g. Can you fork and include one branch only ?
There was a problem hiding this comment.
Also is creating a fork messy due to branching ? e.g. Can you fork and include one branch only ?
Yeah that was the main motivation. We're storing all the configs in a single repo for administrative convenience, but it isn't the best model for users. Additionally we have release and dev branches, which is a complication most users will not require.
I mean they can if they want, but typically I'd expect users would want to have a repo for related experiments, which would often be variations on a single configuration.
There might be some users who'd like to have a multi-configuration repository, say if they were looking at the effect of resolution on a process, but that's quite a bit rarer, and in any case they'd want to select what configs should be in there, and not just everything.
It's a cost of this model of organising model configurations, and part of the motivation of adding the capability to payu to be able to specify a branch to clone directly.
There was a problem hiding this comment.
Not sure I follow. I thought we wanted users to work from a fork so they can upload their experiment branches there (for sharing, safekeeping, provenance and journal data requirements)?
As far as I can see, the only options for forking are main branch only (which is no use at all), or everything (i.e. untick "Copy the main branch only"). It's apparently only possible to have one fork per user, so it makes sense to fork every branch so users have the option of running any config in future, using one repo for everything.
Fixes links and contributes to COSIMA/access-om3#221