[Biopython-dev] biopython on github

[Giovanni Marco Dall'Olio]

On Tue, Mar 17, 2009 at 6:59 PM, Peter <biopython at maubp.freeserve.co.uk> wrote:
>
> Brad and I have been trying this out in practice, and it seems to work OK.
>
> I started a fork to test the patches for Bug 2767, adding quality
> parsers to Bio.SeqIO,
> http://github.com/chapmanb/biopython-seqio-quality/tree/master
> I made a few incremental checkins, pushed to github one by one.
>
> Brad then took a fork of this in order to make some minor changes and
> fix a typo in the documentation :
> http://github.com/chapmanb/biopython-seqio-quality/tree/master

Yes, basically this is the way it should be working.
Usually I do something similar, only I use more the procedure explained here:
- http://www.kernel.org/pub/software/scm/git/docs/v1.4.4.4/tutorial.html
(section 'Using git for collaboration')

I fetch the other branch and call it as master:otheruser-incoming,
then compare the two branches with gitk or with git log
master..otheruser-incoming.


>
>
> At this point the "network" diagrams showed up the two branches as
> diverging.  Brad then sent me a "pull" request, suggesting I might
> want to pull his work into my branch.
>
> Using the git command line tool, I was able to pull and merge Brad's
> changes (as I had made no changes in the meantime this could be done
> automatically),

If you go on 'Fork Queue' on github, it should show other people's commits.
However, I don't trust doing this with a web interface... moreover, it
seems to not work properly some times (it is not clear how it defines
if a commit will 'apply cleanly' or not)

On the same page, there is a 'pull merge request' button, which (I
never tried it) should send a merge request to the selected recipents.

> and then push the merged version back up to github on
> my branch.  At this point my branch and brad's agreed once again, and
> the "network" diagram no longer shows both.  Note that my branch now
> includes a commit from Brad.

Yes, this is right. The graph only shows the commits which differ, so
it included your two branches as a single one.

If you fell comfortable with the git mechanisms, maybe later you could
create a second branch in the 'biopython/biopython' repository, and
call it 'accepted-github-changes', or something like that, which will
collect all the changes that can be submitted to the cvs.


> At this point, Brad may choose to delete his branch, or perhaps make
> further changes.

I wonder if a good strategy with this is create branches only to test
specific changes, and then delete them.
If Brad keeps his branch, later he will have to remember to update it,
which maybe is less trouble than deleting a branch and creating it
when necessary.

> Now all this worked, but I was wondering if the github web interface
> could have simplified any of this, if I'd only know where to click.
> For example, does github offer any way to view a diff between to
> branches?  Or, as I suspect, do they simply expect you to use the git
> tools directly for this?

For my knowledge, there are not such tools :-(.
You must rely on the commit's messages to identify the differences
between different branches.
Maybe they will implement such feature at some point.

>
> Peter
>
> _______________________________________________
> 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