[AstroPy] proposal for astropy version control software and respository

[Erik Tollerud]

> Yes, subversion has revision numbers are sequential.  They are also
> small integers.  You can easily read/write/speak the revision numbers.
> You can easily include them in a note, and recognize them when you read
> them in another note.
>
> Git hashes have none of these features.  They are 160 bit opaque data
> items.  A computer can test them for equality, but it is not practical
> for a human to do that routinely.  You would not write a git hash on a
> sticky note.

Well, in git you can use only the first 4 characters of a hash and it
will work the way a revision number does - that's something you *can*
write on a sticky note.  Occasionally its ambiguous if multiple
commits have the same first 4 chars, but that's pretty uncommon.


> So, git must contain some feature to compensate for this weakness.  For
> example, if git has real tags (which subversion does not), you could tag
> a version when you need to talk about it.  You might even make a
> convention for tag names that are reserved for that kind of use.  It
> wouldn't be quite as convenient as revision numbers, but it would come
> close.
>
> Or maybe there is some non-obvious way of using git where you don't miss
> having the subversion revision numbers.  I don't know.

I'm not sure what you mean by "real" tags in subversion.  Git has tags
that are as simple as "git tag <tagname>" (the current commit - in git
parlance, HEAD) or "git tag <tagname> <commit-hash>" (tag some other
commit).  These can be local to you or you can push them up to the
repository.  Tags can also be "lightweight", or annotated - the latter
is actually a commit object and thus can have associated messages and
be signed and the like.

Generally the convention is to use tags locally as shorthand for some
commit you often go back to, and publically tag version numbers.  Then
the "git describe" command basically gives you all the information you
need.


> All I'm asking for is a commitment that somebody will spell out the
> details after git is selected.  I've had that in off-list discussions,
> but I wanted make the case publicly.

I would guess we all agree on this, although I'd say it is not really
even a git-specific point (although you're right that it is somewhat
*more* important in a DVCS due to the flexibility).  If this isn't
done to your satisfaction once we actually have the repository up and
running, hopefully it can then be corrected, as there will then be
something specific to work on.



-- 
Erik Tollerud