[Biopython-dev] biopython on github

[Brad Chapman]

Hi all;

> >> As my initial branch/fork of biopython still exists but is being
> >> deleted, it seems in the meantime I can't create a new branch
> >> of biopython.
[...]
> True, the network page is still there for me. But
> http://github.com/peterjc/biopython-seqio-quality/ which redirects to
> http://github.com/peterjc/biopython-seqio-quality/tree/master
> shows me just a "This repository is being deleted" page.

Peter, the repository deletion was very quick for me, so it looks like it
got stuck somewhere with the GitHub downtime. Does this help for getting it
removed:

http://originblog.wordpress.com/2008/04/28/github-tips-removing-a-remote-branch/

> > I see that you have renamed your fork as seqio-quality. Ok, but I
> > think it is better to keep the fork's name as 'biopython', and then
> > create many branches inside it.
> 
> I don't think I had entirely understood github's use of fork versus branch.
> I'll have so do some more reading and try again once my account has
> settled down.  Thanks for the details in your email.

Wow, now I am mad confused. I thought forks and branches were
conceptually the same. Giovanni, it seems like you are suggesting one
branch (the GitHub fork) and then a second branch (the git branch 
command). We were thinking of a standard case as:

1. Fork the Biopython trunk at GitHub. Name this something so it
makes sense what the fork/branch is for.
2. Work on the fork/branch. If you want, invite others to work on it
with you.
3. When finished, be sure you are up to date with the master
Biopython trunk.
4. Submit the fork/branch for inclusion in Biopython.
5. Once included, delete the fork/branch.

Which parts of this fall out of "standard" git practice? In general,
we should strive to keep this as simple as possible. If using Git is
complicated then we are losing a lot of our advantage over CVS/patches.

Giovanni, the example commands were very helpful; I added details to the Git
page on how to see diffs of branches:

http://biopython.org/wiki/GitMigration#Evaluating_changes

Brad