Yang Tse wrote:
> content is provided in files and files have a history and as
> such a revision number.

Git history is not linear, and is updated independently at different
locations without having to be online all the time, so a global
incrementing version number is fundamentally impossible.

> Another thing that shows that git is yet in its infancy is the use of
> internal keys as external references. GUID's are fine as primary keys
> in a database,

They aren't internal keys, and they aren't GUIDs!

They are strong crypto hashes of the entire history up to that point.

And yes, they are checked.

> but only for internal purposes. Exposing these as the primary way of
> identifying elements, no matter if these are code commits, financial
> transactions or cake recipes makes little sense, except maybe for
> debugging purposes.

Good luck arguing that one with git users :-)

What other identifier can you use to identify a point in history
globally, without requiring every user to be online when they commit
things locally?

That's a serious question, btw. If you have a good solution I'd be
interested.

All the VCSs based on things like CVS/SVN two-way replication have a
worse problem: version numbers increment, but are different at each
location. When someone tells you to look up version x.y.z, you have
to use the master server holding x.y.z or you can't look it up. What
if it's down, corrupt, or you're working offline? Then you're stuck.

-- Jamie
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-03-26