OHDSI Home | Forums | Wiki | Github

GitHub - command to sync a forked branch with the original repo

Developers
#1

In submitting pull requests (=PR), it is good to have an OHDSI project forked to a personal repository. (the only way to submit PR, in fact)

It can happen, that such fork already exist and is way behind the master branch.
Instead of deleting the fork (which takes via web UI quite few steps) - can someone please post the process (command) to make a personal repo fork catch up with the master branch.

E.g., for submitting PR to https://github.com/ohdsi/commondatamodel

tagging @Chris_Knoll

#2

Just had to figure this out as well.

First, you have to make sure your fork is linked to the original. You only have to do this once per fork:

git remote add upstream https://github.com/OHDSI/Achilles.git

Then, whenever you want to force your fork to catch up you do this. WARNING: this overrides any changes that you have made to your fork that didn’t go back in to the original!

git fetch upstream
git reset --hard upstream/master
git push origin master --force
#3

The developer guidelines for managing branches and forks is described here:
http://www.ohdsi.org/web/wiki/doku.php?id=development:ohdsi_github_projects_v2

@schuemie is correct about creating the upstream origin (via git remote add), however, you should be able to pull down changes to your repository using the command:

$ git fetch upstream # will fetch latest commits from the upstream repository
$ git checkout master
$ git merge upstream/master --ff-only # merges the commits from upstream/master into local master using fast-forward only

The git merge --ff-only will fail if your master branch does not ‘fast forward’ to the upstream’s master. As long as you never commit anything directly into the master branch of your fork (ie: always work off feature branches, and create pull requests from these feature branches) you shouldn’t need to do a git reset to resync your master branch to the upstream.

To visualize how PRs flow through your local repo to upstream then back into your fork:

fork repo ->
  git remote add upstrream ->
    git checkout -b new-feature-branch ->
        git add ...
        git commit....
        git push origin new-feature-branch ->
            Open Pull Request
            Upstream Repo Accepts PR into Master
        <- git fetch upstream
    <- git checkout master
   <- git merge upstream/master
<- your master branch now has commits from new-feature-branch

Note that you never merged your own feature branch into your fork’s master. Always get updates from the upstream master.

This process isn’t much of a headache, it becomes cumbersome when you want people from different organizations sharing a feature branch on a fork (and the people don’t have commit access to push changes to the fork).

2 ways to go about this:

  1. the fork owner delegates permissions to people who want to collaborate
  2. the main repo grants permissions to people they want to trust to create and push branches.

-Chris

#4

I found the information about granting permissions to your personal repository:

https://help.github.com/articles/inviting-collaborators-to-a-personal-repository/

So I’d argue that the OHDSI repos don’t need to open up to everyone for commit rights, if there’s a feature that a group of people want to collaborate on, they could have one person fork the repo and grant permissions to the collaborators that want to contribute. This saves the OHDSI organization from having to clean up older permissions and that responsibility can be left to the individual fork maintainers.

t