[Biopython-dev] Working directly on the main git repository

[Eric Talevich]

On Mon, Jun 7, 2010 at 5:35 AM, Peter <biopython at maubp.freeserve.co.uk>wrote:

> Hi all,
>
> I thought I'd write down some notes about how I've been using git recently.
> This may be of interest to any of the other core developers (those of us
> with read-write access to the main repository), and I might get some good
> tips from any discussion. The key point is that I have read+write access
> to two repositories on github (the official repository AND my own fork),
> so there are different advantages/disadvantages about which I choose
> to work with directly as my main repository.
>
> [...]
>
> Instead, I have a github repository of my own (what github calls a
> fork), and I push branches there.
>
> http://github.com/biopython/biopython - the official branch(es)
> http://github.com/peterjc/biopython - my branches
>
> How does this work in practice? Like this - I clone the master
> and add a reference to my repository (and I do the same when I
> want to grab a branch from another developer):
>
> git clone git at github.com:biopython/biopython.git
> cd biopython
> git remote add peterjc git at github.com:peterjc/biopython.git
> git fetch peterjc
>
> Then make a new local branch as usual, and when ready to share
> it publicly, I push it to *my* repository on github:
>
> git branch new-work
> git checkout new-work
> git commit ...
> git push peterjc new-work
>
> This would then appear as a new-work branch on my github page.
> Then if I (or someone else) wants to access these branches later
> (e.g. from another machine) just use the checkout tracked remote
> branch. For example,
>
> git clone git at github.com:biopython/biopython.git
> cd biopython
> git remote add peterjc git at github.com:peterjc/biopython.git
> git fetch peterjc
> git checkout -t peterjc/seqio-imgt
>
> This then looks like a normal branch (called just "seqio-imgt" in
> this example), but git knows it is linked to the remote branch on
> the "peterjc" repository (not the origin which is the "official"
> repository).
>

This looks reasonable to me. I'd add that the procedure to delete a public
branch from your personal fork on GitHub is a little obscure:

git branch -a   # list local and remote branches
git branch -d new-work   # delete a local branch that's been merged already
git push peterjc :new-work  # delete the public branch from GitHub

This doesn't do what you'd expect:
git branch -d peterjc/new-work

That only removes your local reference to the the public branch; the branch
is still visible on GitHub.

(It's kind of hard to find in the GitHub documentation.)


I'd have to check, but I guess that if the original git clone is done
> with git://github.com/biopython/biopython.git instead (read only
> access) the same procedure could be used by non core devs.
> However, I'm not sure this is clearer for them. I think the current
> procedure (on our wiki) where you add a remote reference to
> the "upstream" official repository works better in this case.
>

I still have an "upstream" reference to the main repo. I wouldn't want to
accidentally push something foolish to the main repo with a stray "git
push"... better to have the safe thing happen by default.

If the initial clone was from biopython master, and you later create a
personal forkon GitHub, then it's not too hard to switch the references
around in your local repo to make the public fork your "origin".

-Eric