D Programming Language source (dmd, phobos, etc.) has moved to github

[Ulrik Mikaelsson]

> That's the same exact concept, isn't it? My understanding is that a clone of
> a DVCS repository *is* a distinct DVCS repository. So, yea, like I said, you
> have to specify "which repository". The "common dev" repository. The "main
> stable repository". The "only shared repository this small project actually
> has". Or "Bob's repository" for what little that would be worth.
Mostly a side-note, but in many DVCS:es (git in particular, but both
bzr and hg has it too), history rewriting is allowed, even encouraged
under some particular circumstances. In that case, the SHA-1 revision
will CERTAINLY change, while even repo+number is not very reliable.
Some kernel-branches are maintained like that, for example.

Furthermore, a related hg-anecdote; Personally, for my work-flow I
often use history-rewriting to jump around, amending patches, rebasing
them before pushing, etc. I've become very accustomed to it, and find
it extremely useful. When trying out hg a while back (to make patches
for LDC IIRC), the attempted linear-history was actually one of my
biggest disappointments. I quickly ended up in a situation where all
my patches looked like a zig-zag-stacked hodgepodge of stuff, many of
them not intended to even keep in the repo. When reading the docs
about it, the only useful suggestion I found was to create a new repo,
and cherry-pick what I wanted from the old. It's possible this were
mostly due to my inexperience with Hg, but it strengthened my
conviction that the unrealistic linear-numbers of a non-linear history
are really just shoe-horning in something for newbie-comfort, but
quite off as a model. For me, It is the deal-breaker for hg.

> I don't understand why you think I'm claiming anything of the sort. I never
> said anything like that. I keep saying over and over and over and over and
> over and over and over....."changeset number **PLUS WHICH REPOSITORY (and
> maybe branch, depending how the given system chooses to work)**"
How should you linearly number the two chains A > B > C and A > D > C
? Is it A, B, D, C or A, D, B, C? Should they be inter-vowen by
commit-time, or what?

>>> Additionally, Hg's approach provides a trivial way to disambiguate hash
>>> collisions. I know that Git book brushes it off as "very rare", but it's
>>> not
>>> as if nobody's ever going to run into it.
>> Um, what method is that?
> Version number together with being specific about which repository.
Again, version-number + repo is not 100% when history-rewrite is possible.

>> Also, saying that SHA-1 hash collisions are "very  rare" is a bit of an
>> understatement.
> Point is, it's possible and it's going to happen at least to someone, and
> frankly, such things *have* happened. Winning the lottery and getting hit by
> lighting are *extremely* rare, and yet there are a *lot* of people who have
> had it happen. The problem is they're taking "rare" (doesn't matter what
> superlative is used) and pretending it's the same as "impossible". Airplane
> crashes and major earthquakes are extremely rare, but they sure as hell plan
> for what happens should such an event occur.
Getting hit by lightning isn't really on the same scale as SHA-1 collisions.

According to Wolfram Alpha, the odds of being struck by lightning in a
given year is one in 750000. If I've understood things roughly right,
(probabilities aren't my strong side) the best possible attack for
SHA-1 requires 2^52 attempts (Note: intentional attack, pure random
chance is likely MUCH higher). That means that, given a very big
project of 1 million commits (2^20, by comparison Linux is at 232k
atm), the chance of intentionally hitting a collision is 1 in 2^32 =
4billion.

Suffice to say, comparatively there might be a prospering market for
current-insulating clothing.

I guess, when every household on earth are running it's own
kernel-project, git might have to upgrade to SHA-512. (Hg too, btw. I
think the REAL, internal revision-id:s for HG is sha-1 too, aren't
they?)