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

Peter biopython at maubp.freeserve.co.uk
Thu Dec 16 18:09:36 UTC 2010


2010/12/16 Eric Talevich <eric.talevich at gmail.com>:
>
> 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.

Got it.

> 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.

I should probably start doing that more often myself.

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

Sounds good.

Peter




More information about the Biopython-dev mailing list