[Biopython-dev] Features of the GSOC branch ready to be merged

[Eric Talevich]

2010/12/16 Peter <biopython at maubp.freeserve.co.uk>

> 2010/12/16 Eric Talevich <eric.talevich at gmail.com>:
> > On Thu, Dec 9, 2010 at 2:03 PM, Eric Talevich <eric.talevich at gmail.com
> >wrote:
> >
> >> On Tue, Nov 30, 2010 at 10:45 AM, João Rodrigues <anaryin at gmail.com
> >wrote:
> >>
> >>> Hello all,
> >>>
> >>> I've been looking at the code I wrote for the GSOC to see what is ready
> to
> >>> be merged in the main branch. I have to thank Kristian and whoever
> >>> participated in the Python & Friends for the input.
> >>>
> >>>
> >> Hi João,
> >>
> >> It sounds like everyone is happy with this branch:
> >> https://github.com/JoaoRodrigues/biopython/tree/atom-element
> >>
> >> So I will try to fetch your branch, correct the spelling of the
> >> IUPACData.atom_weights references (unless you beat me to it), test,
> rebase
> >> onto biopython/biopython/master, and merge it this weekend.
> >>
> >
> >
> > I just did this and pushed it to biopython/biopython/master. The
> Biopython
> > network graph on GitHub looks reasonable and the tests pass, so I think
> it
> > all went OK.
> > https://github.com/biopython/biopython/commits/master
>
> Hi Eric,
>
> Yeah, it looks OK. For future reference (and I'm trying to be constructive
> rather than critical), there were a few things like these commits which
> could have been omitted:
>
>
> https://github.com/biopython/biopython/commit/06008c298c14a2178bebf1f9795c0740f02937b1
>
> https://github.com/biopython/biopython/commit/f4568562a914d31f04a55148b9aa927e849b101d
>
> https://github.com/biopython/biopython/commit/6c7ef358e5f93599ca165ce8e7b46261106e2b06
>
> https://github.com/biopython/biopython/commit/9a4a3a5b968e8918fd6ca02b436382c1e3c5d604
>
> Also there appears to have been a net change to Tests/PDB/1A8O.pdb
> (just white space so probably harmless).
>
> In this particular case I would have been tempted to have collapsed
> it all into just one or two commits - it is actually quite a small
> change overall, and much easier to follow. As it stands we see
> several iterations of the code (e.g. adding them removing the
> hetatm arg, removing then restoring elements in one of the test
> files). In some respects this is more a matter of taste, the end
> result is the same. What are your thoughts on this Eric (et al)?
>
> Regards,
>
> Peter
>


Ah, sorry. I think we had a difference in understanding what I was planning
to do -- "git rebase" can straighten out a branching history, and also
squash multiple commits into one with the "-i" option. I only did the
former, though in retrospect the latter would have been easy to do, too.

For the public benefit, these are good ways to keep a commit history clean:

1. git commit --amend

Squash the current change set onto the previous commit. This is great for
eliminating "fixed a typo" commits while you're working.

2. git rebase -i

Rearrange and simplify a series of commits (interactive rebasing). This is
the best way to clean up a personal branch just before publishing; I could
have done this to João's atom-element branch after rebasing onto the current
master and fixing the merge conflicts, just before adding my own small
correction.

3. git merge --squash

Flatten a branch into a single commit, which is then applied to master (or
another branch). I didn't know about this until Peter mentioned it.


I use the first two regularly but haven't tried the third yet. In the
future, for João's other feature branches, I'll use "git merge --squash" for
small overall changes and a gentle degree of "git rebase -i" for larger
changes. But interactive rebasing does require a solid understanding of how
the commits in a series fit together, so I think it's best if the original
author does the heavy lifting there.

I'll note here that the Mercurial and Git communities differ in opinion here
-- Mercurial supports single-commit rollbacks but strongly discourages
editing the commit history beyond that. Having been burned by history
editing several times, I can understand their perspective, but I think using
Git's features carefully yields a nicer result.

Best,
Eric