[AstroPy] proposal for astropy version control software and respository
erik.tollerud at gmail.com
Fri Jul 15 20:54:19 EDT 2011
> For those of us who are not very familiar with git and github, can someone
> suggest a source for additional information?
I'd say the github help page ( http://help.github.com/ ) is probably
the best resources out there in terms of getting started quickly,
along with the community book as suggested by Michael.
If you're on OS X, there's also a few different git GUI tools - github
has an app (get it from their web site), and gitx
(http://gitx.frim.nl/) is a nice free history viewer. There are some
nicer ones that can replace the command line interface completely if
you're willing to pay: the best seem to be Tower (
http://www.git-tower.com/ ) and SourceTree (
http://www.sourcetreeapp.com/ ). There are a variety of open source
options for linux (git cola, gitk, gitg, giggle), although most linux
people are happy with the command line. There also exist some for
windows, but I don't really know much about those.
> I'd also like to note that in the discussion of the previous "simple
> yes/no poll", several people raised objections that this was too coarse
> a metric and that there is value in being able to signify "yes but" or
> "don't care" & so on. I'd like to second those objections and request
> that the Coordinating Committee formulate polls that allow more nuance.
This is a very good point - I had been thinking we should do this for
future documents, but it didn't occur to me that it's equally relevant
for this poll... In the future, would "Yes", "Yes, but with
reservations", and "No" be an acceptable set of options, or would you
prefer something more fine-grained than that?
> - If the project will use git, the git advocates have a responsibility
> to present a clearly-defined work flow for each role in the project.
Absolutely agreed - if the poll passes muster, we will certainly do
this ASAP. Probably the easiest thing is to follow the standard
workflow used by ipython, numpy, and scipy - it's based on a
customizable template document called "gitwash", an example of which
you can see at http://matthew-brett.github.com/pydagogue/gitwash_build.html
> But it would sure suck to lose the revision numbers that subversion has
> (but git does not) and not get something pretty intensely useful in
> return. I hope you git guys know what that is.
As an FYI, there are actually ways to get revision numbers in git (as
long as it's understood that those "numbers" aren't unique across
different forks of a repo), although it isn't quite as easy as svn, of
More information about the AstroPy