"Warning: you are leaving 1383 commits behind" while installing phylesystem-api

[jar398]

Using branch master of repo phylesystem-1
Branch master set up to track remote branch master from origin.
From https://github.com/OpenTreeOfLife/phylesystem-1
   101d7a5..06f7c68  master     -> origin/master
Warning: you are leaving 1383 commits behind, not connected to
any of your branches:

This is on api.opentreeoflife.org. I don't know what it means, but it looks like a problem to me. Not sure whether this is a phylesystem-api issue, a peyotl issue, or an opentree (deploy/setup/install-api.sh) issue.

[mtholder]

Commits go in the working repo.
when we want to share, we:

1. pull them from the working repo to a local mirror, and
2. push them from the mirror to GitHub

the upshot is that the working copy has not directly talked to GitHub in months. It thinks that it is hopelessly behind. But in fact its content has been moved along to GitHub.

I think that we need to make git_refresh in opentree/deploy/setup/functions.sh fancier if we want to avoid this. We are recreating master to match the GitHub repo at that point. I think that is where the message comes from. A bit hard to tell with all of the bash commands in rapid succession w/o set -x option.

[jimallman]

It's possible that we're doing the right thing and it's a bogus warning. Here's a discussion of similar warnings when moving to and from the master branch.

There was a related bug in Git that was fixed in git v1.7.11.5, so this warning might disappear if we update the git client software.

[jimallman]

FYI - We're currently running git 1.7.10 on api.opentreeoflife.org:

$ git --version
git version 1.7.10.4

It looks like we install git with apt-get, so we might need to jump through a few hoops to get the newer version. Here's a simple incantation using the git-PPA repository.

[mtholder]

I think that the cleanest thing to have a different function in the deployment scripts which makes sure that all branches from the working repo get pulled to the mirror and then pushed to git hub. If the server is offline, then we can follow those steps with "git fetch origin" in the working repo so that the working repo knows that its commits have made it to GitHub

[jimallman]

the upshot is that the working copy has not directly talked to GitHub in months. It thinks that it is hopelessly behind. But in fact its content has been moved along to GitHub.

I think this whole notion of being out of sync with remote repos is a red herring. From my reading, the warning message above is entirely about losing track of commits in the local repo because they're not associated with a branch. It usually appears if you commit changes while git is in a "detached HEAD" state, then switch to a proper branch.

This is why I think we're seeing the bug described above, unless we're actually doing meaningful work in a detached-HEAD state.

[jimallman]

...unless we're actually doing meaningful work in a detached-HEAD state.

I should clarify. One way we might inadvertently do this is by using git checkout {SHA} instead of 'git reset {SHA}`. The latter will properly move the current branch pointer to the specified commit.

Without this branch (or tag) pointing to our series of commits, they'll exist only in the reflog and disappear in the next round of garbage collection.

Apparently a similar situation can arise if we checkout a remote branch without creating a corresponding local branch.