Recommendation to clone vs fork? about article_templates

[mrshirts]

So, I don't know that tracking is 100% needed; some people will end up starting it some other way, so we will know many, but not all of the people who are writing papers - but also many of the people who fork will never actually get around to submitting.

Looking over here: https://stackoverflow.com/questions/6286571/are-git-forks-actually-git-clones

Forks are just clones with some extra database connections. For a clone, vs a fork, then "When you clone a GitHub repo on your local workstation, you cannot contribute back to the upstream repo unless you are explicitly declared as "contributor". That's because your clone is a separate instance of that project."

I don't know that we actually want most people contributing BACK to the templates (unless they are actually contributing to the templates, that's a different category).

But it's subtle, so perhaps I'm taking the wrong slant.

[davidlmobley]

I guess my take is that the model I learned first/which is most obvious to me is:
a) Clone if you're part of the project and will want to change it
b) Fork if you're not and are going to be diverging

So I was just thinking that if we ask (Github-aware) people to clone it rather than fork it we would explain why, whereas forking would be clear. For the people who don't know what either means, it doesn't matter.

But if fundamentally they are the same this is no big deal.

[mrshirts]

I guess my understanding is the other direction: a fork maintains connections in github, so it's useful if you want to contribute back. a clone is bare, so is best when you will be doing something different!

[davidlmobley]

@mrshirts -- I think there is a very important operational difference/difficulty:

• With your procedure (as per your documents) they actually have to create a new repository by moving the files into it. Perhaps this is fine, but it adds extra steps, and requires them moving all of the files they need over, so they will often forget things we would like them to have (the license, etc.).
• With my procedure (forking) they already have a new repository and can just start working on it, and have to REMOVE files they don't want.

Perhaps @jchodera has other thoughts on which approach is better.

[davidlmobley]

(Also, a clone is not bare unless you do special invocations, it seems: https://help.github.com/articles/duplicating-a-repository/ ). I think basically a fork is a clone that is "free" from the original (though still connected for tracking purposes) so it can be extended/modified even if you don't have write permission to the original, whereas a clone is still tied directly to the original so you can't make server-side updates unless you get permission.

In other words, a fork is a special type of clone that people often need because they don't have write permission to the original.

Your procedure, I think, is just using a clone to create a new fresh repo from scratch.

[davidlmobley]

I thought about this some more and also started creating my own repo for a paper, and realized that you're right, Michael. It'll be simpler for them if they are creating their own from scratch and putting in the files they need. We should probably just make sure to put in a careful list of exactly everything to put in. :)

[jchodera]

Are you sure that's easier than forking a repo with an prebuilt structure? It seems like it would be much better to have a template best practices paper with the repo organized how we like, README.md files structures as we hope, and manuscript template in the appropriate style. Overleaf does this for their manuscript templates, and it seems to work really well.

I think asking everyone to pull in files manually is just asking for trouble and encouraging heterogeneity.

[davidlmobley]

Yeah, I guess both have their pros and cons. If they fork, then they have the commit history, etc., from this repo, plus they have to clean out files they don't need, change the repo name, change the description, etc., which is a bit of work, but at least they'll have all of the right files. But if they create a new repo they have to copy IN all of the right files and set it up properly. Neither of these is idiot-proof...

[mrshirts]

To some extent, we may have to experiment and find out which kind of idiots well-trained computational scientists most resemble.

…

On Sat, Sep 9, 2017 at 11:08 AM, David L. Mobley ***@***.***> wrote: Yeah, I guess both have their pros and cons. If they fork, then they have the commit history, etc., from this repo, plus they have to clean out files they don't need, change the repo name, change the description, etc., which is a bit of work, but at least they'll have all of the right files. But if they create a new repo they have to copy IN all of the right files and set it up properly. Neither of these is idiot-proof... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEE31OjuZc3P4p_a_3WvPfUtXq9mbCMRks5sgsYRgaJpZM4POvl4> .

[jchodera]

I was talking to @dgasmith this evening, who suggested that cookiecutter may be the right solution for this problem.

[mrshirts]

I'll nominate john to figure out how that would work (after the conference, of course!)

[mrshirts]

@dgasmilth now suggest mirrors:

https://help.github.com/articles/duplicating-a-repository/

[davidlmobley]

One issue I keep forgetting about is this: What instructions do we give them so that they have a new, independent repository that they can push, pull, and fetch from without dealing with the original? I should try this for mirrors. Ideally you'd want it to be totally separate/disconnected from the original at this point.

[dgasmith]

Mirrors break all connections. It is basically a fork, but it drops the GitHub magic that links projects together. Goes back to the true Git and not GitHub.

…

-Daniel Smith Sent from my iPhone.

On Sep 12, 2017, at 11:51, David L. Mobley ***@***.***> wrote: One issue I keep forgetting about is this: What instructions do we give them so that they have a new, independent repository that they can push, pull, and fetch from without dealing with the original? I should try this for mirrors. Ideally you'd want it to be totally separate/disconnected from the original at this point. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[davidlmobley]

OK, that's perfect, then.

@mrshirts - should we mark this as resolved and just update the docs to tell people to mirror?