[AstroPy] proposal for astropy version control software and respository

[Erik Tollerud]

Some of this was discussed in Tom's e-mail a few days back, but I just
wanted to address a couple points that had been left dangling here.

On Mon, Jul 18, 2011 at 11:37 AM, Victoria G. Laidler <laidler at stsci.edu> wrote:
>
> One problem with this poll that I haven't seen mentioned yet is that it
> conflates use of git as the VCS with use of github as the hosting site.
> These are in principle independent. The hosting site is not just a place to
> stash the repository; it also provides related tools that are critical to
> planning & managing workflow, like tickets/issues, history/timeline, nice
> tools to view diff, history, & so on.

You're absolutely right that these are in principal independent, and
for some VCSs there are number of rather different competitive
options.  But in the particular case of git, there's really nothing
even approaching github in terms of functionality, particularly for
workflows that involve regularly merging other projects (as the vision
here calls for).  In fact, for a number of people I know that use it,
github the major selling point of git, as opposed to the other way
around.



On Tue, Jul 19, 2011 at 6:49 AM, Matthew Turk <matthewturk at gmail.com> wrote:
> For what it is worth, enzo and yt are both astrophysics projects and
> both use and love mercurial; the buy-in feels to be much lower than
> that of git, it's much more straightforward, and extensions are very,
> very easy to write.  The primary hg hosting solution, BitBucket, has
> substantially improved pull requests and other collaborative features
> recently, and this has I believe brought it in line with GitHub in
> many ways.

Admittedly this is partly a matter of personal taste... I've used both
and I actually prefer mercurial/bitbucket for small/private projects,
but for to me it has seemed like git works for more complicated needs
(like we certainly have here).  In addition, most of the base python
scientific packages are now on github (not counting more
domain-specific tools like enzo and yt, of course!), so it seemed like
the more natural choice.

The other thing is that there's a hg-git plugin that lets you use
mercurial to interact with a git repo, and as far as I can tell, it
works flawlessly.  So there's actually nothing stopping you from using
hg to both push to and pull from a github repository.


> One point I feel very strongly about is that under no circumstances
> should a scientific code make a habit of 'rewriting history' or
> changing the hash numbers of existing revisions.  This would, for
> instance, be part of a rebase-based workflow with git or on github.
> hg discourages rewriting history, but it seems quite prevalent with
> git.  So even if git/github is chosen as a platform, I sincerely hope
> that a workflow that does not change existing revision numbers in any
> published repository is selected.

Actually, github specifically says that you should not go back and
alter anything actually pushed to a main repo (see the warning at the
top of http://help.github.com/rebase/ ) for exactly the reasons you
point out.  So I 100% agree that altering the history of anything
that's actually been put out there as part of the master branch or
certainly for any release, is a huge no-no.

Rebase is, however, useful for squashing commits you make as part of
the process of fixing a problem/implementing a feature branch.  This
can make the history much more readable as it isn't full of "fixed
tiny typo" sorts of commits.  Additionally, it's good for merging
patches that were merged with the master branch somewhere along the
way, as this greatly simplifies the merge network.  IPython actually
has a policy of doing this for all significant patches to be merged as
long as it is reasonably possible.

So you're completely right that re-writing history is a thing to be
*very* careful of, and to only use in certain restricted cases, but I
think the base mercurial philosophy of basically no re-writing ever is
a bit extreme (and in fact, that's why plugins like the rebase plugin
were eventually developed for mercurial).


-- 
Erik Tollerud