search

oist / LaTeX-templates

Graduate School LaTeX templates for Lab rotation proposal + report, OIST beamer and Thesis + thesis proposal
MIT License
61 stars 56 forks source link

Workflow question #2

Closed leios closed 5 years ago

leios commented 5 years ago

Due to the way this repository is structured, it is unlikely for users to directly fork it to create their presentation / Thesis / Proposal. Instead, users will copy the relevant sections, modify the license, and create a new repo entirely (such is the case here: https://github.com/leios/thesis).

Because of this, if there is a change in the relevant template, it is difficult to merge those changes to the working repositories. It is also difficult to make PR's because the working repo is not a direct fork of OIST/LaTeX-templates.

This is ultimately not a huge issue, but I am wondering if it might be better to split each template into its own repo (OIST/PhD-thesis, OIST/LaTeX-presentation, OIST/PhD-proposal, etc...) such that it's easier to pull changed from upstream or make PR's?

Admittedly, these are OIST templates and most OIST users do not actively use git or version control. As such, this is a really low-priority issue for now.

jiegillet commented 5 years ago

Thank you for the input. I've been thinking about this when I created the repo and ended up going for the simple, all in one, I-do-not-know-git solution, for the reasons you mentioned.

So far, there has been little community contributions to the repo, yours and Tadashi's being the recent exceptions, but it's worth thinking about.

jiegillet commented 5 years ago

Update: After some offline discussions, we realized that unlike some other projects, a template is not a natural environment for sending PRs.

Say that you clone the repo and start writing the thesis, you add files, delete others, change things and commit along the way, by the time you realize something could be improved in the template, your repo is significantly different from upstream, and merging a PR is probably much harder than cloning a separate copy and making modification there. The other direction, merging a change made upstream is possibly easier, but that won't be very frequent.

In other words, this repo is best used as a reference, not a working directory.