Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modify setup.sh to allow updating #1

Merged
merged 1 commit into from
Oct 5, 2014
Merged

Modify setup.sh to allow updating #1

merged 1 commit into from
Oct 5, 2014

Conversation

synapticarbors
Copy link
Member

@mczwier: After looking at the new setup.sh, I realized that if any of the former submodules were updated, that a novice user wouldn't have an easy path to updating the code. I changed things around so that if the directory containing the package doesn't exist, it's cloned, but otherwise the script does a pull to get any new changesets, and then updates to the revision specified by the script. This assumes that the changeset that we want lives in master and it's going to be merged into master, which is currently true but may not always be. I think this should be pretty safe, as I'm assuming the average user won't ever modify the code so uncommitted changes and merge conflicts won't happen. Developers should have a handle on the structure of the code and git that they'll know the correct path to take when making modifications.

Now a user should be able to just run setup.sh to get current with the subrepos. A git pull (or git fetch/git merge) can be done to get the main repo at the newest revision as before.

There may be a cleaner way of doing this.

Anyways, I thought I would kick off discussing code decisions in Github using the first PR for the repo. I think in general though, we should get in the habit of not always pushing directly to master so that some code review can take place.

@mczwier
Copy link
Member

mczwier commented Oct 5, 2014

Looks good to me. I also like the idea of inspecting pull requests and merging, rather than just directly modifying master. Also, if there's a cleaner way of doing this, it's not immediately obvious.

mczwier added a commit that referenced this pull request Oct 5, 2014
Modify setup.sh to allow updating of subcomponents
@mczwier mczwier merged commit 2acb000 into master Oct 5, 2014
@synapticarbors synapticarbors deleted the setup-jla branch October 8, 2014 03:29
KarlTDebiec pushed a commit to KarlTDebiec/westpa that referenced this pull request Aug 19, 2015
integrated most remaining wiki pages into sphinx
ltchong pushed a commit that referenced this pull request May 6, 2020
Update repo to the latest py3 WESTPA
synapticarbors pushed a commit that referenced this pull request May 18, 2020
Update repo to the latest py3 WESTPA

Former-commit-id: 17215f2
ltchong pushed a commit that referenced this pull request May 19, 2020
synapticarbors pushed a commit that referenced this pull request Jun 22, 2020
Update repo to the latest py3 WESTPA

Former-commit-id: 1e5b52b [formerly 17215f2]
Former-commit-id: 042e374
synapticarbors pushed a commit that referenced this pull request Jun 22, 2020
Update repo to the latest py3 WESTPA

Former-commit-id: 17215f2
synapticarbors referenced this pull request in synapticarbors/westpa Jun 24, 2020
Modify setup.sh to allow updating of subcomponents

Former-commit-id: 2acb000
synapticarbors referenced this pull request in synapticarbors/westpa Jun 24, 2020
integrated most remaining wiki pages into sphinx

Former-commit-id: ef1c41a
jdrusso pushed a commit that referenced this pull request Sep 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants