[Biopython-dev] biopython on github

[Giovanni Marco Dall'Olio]

On Fri, Mar 20, 2009 at 1:55 PM, Brad Chapman <chapmanb at 50mail.com> wrote:
> 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.

Consider that the term "fork" is specific to github, and has nothing
to do with git. There is no 'git fork' command.
When you do a 'fork' in github, what it does it to create a personal
'space' on your account on github, to host all your personalizations,
including new commits and also new branches of development.
It is a kind of 'working space', that indicates all the work you have done.

I understand it seems a bit complicated at first :-( but I think that,
without using github, it is even more difficult to understand these
things.

In your account you can have more than one experimental branch. For
example, I can create a branch called 'experimental-xzy-parser',
another called 'personal modifications', and keep the master branch as
it is (or rename it).

if you want to contribute to my 'xyz parser', you can fetch this
branch into your space, with a command like:
$: git remote add giovanni <my url on github>
$: git pull giovanni master:experimental-xyz-parser # (not sure about
this last command)

this should create a branch called 'experimental-xyz-parser' in your
computer, so you can work with it, make modifications, and later push
it to github (where it will happear in the network graph).




> 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
> _______________________________________________
> Biopython-dev mailing list
> Biopython-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biopython-dev
>



-- 

My blog on bioinformatics (now in English): http://bioinfoblog.it