incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: Votes for git repos - commit id vs tag
Date Sat, 20 Dec 2014 09:35:51 GMT
On 20.12.2014 07:16, Niclas Hedhman wrote:
> Tags are at best a convenience, and nothing else. But so are commit id,
> since in the long-term, GIT may not prevail and the commit id is in effect
> an internal artifact of Git itself, not the concept of version control
> systems. Compare how commit numbers from Subversion are imported to Git
> repositories, or not... But tags are imported, if the ttb structure in
> subversion is used.

Any release is cut from a current canonical repository, which is always
hosted on ASF infrastructure. The point is that current releases should
be identifiable in the current repository, because anyone who votes on a
release /should/ verify that the tarball matches some state in the repo;
otherwise they don't know what they're signing, and the release isn't
repeatable; that would sort of negate the whole point of version control.

In the case of Git, the commit-id is the most stable global identifier
for a particular state of the repository. (I say "most stable" because,
in general, Git history is mutable ... sigh).

If at some future date the repository is imported in some shiny new
version control system, that new system is bound to have some kind of
global state identifier, mutable or not; and commit-ids may or may not
be accurately represented by it; but that's completely irrelevant for
current releases. It's marginally relevant for reproducing past
releases, but that can be solved by archiving the whole "old" repository.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message