[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] git foo
From: |
Thomas Lord |
Subject: |
[Gnu-arch-users] git foo |
Date: |
Thu, 13 Oct 2005 10:33:30 -0700 |
Y'all are doing pretty well (Adrian, Miles, Martin).
My $0.02...
Yes, the fast-commit properties of git
are winning. revc picks those up and fixes some deep
flaws in git (weak integrity checking, awkward storage,
inappropriate reliance on SHA1). From the arch perspective,
this is a lot like the combination of two old ideas:
revlibs that don't depend on unix hard links and
commit-to-revlib instead of commit-to-archive.
Yes, name-independent file ids are critical to rename-handling
smart merging. The arch inventory system is a *pretty good*
framework for that and there seem to be no serious
other contenders. Yes, sure, it might be worth adding
the option to store the inventory in a single file, as has
been long acknowledged. The convenience of taglines --
eliminating the intrusiveness of an explicit "rename" command --
is hard to beat, especially if (as in git/revc-style commits)
the expense of examining taglines can be deferred to merge-time.
No, trying to infer renames by glomming over history that doesn't
include logical file ids is a lousy solution. The usual
problems of expense and history lacunae apply.
The git-family tools bug me because (among other things):
~ they are weak wrt SHA1 cracking
~ the blob format, with the header on each file, is
wasteful and awkward
~ git's "big bag of every file in history" needlessly
creates needs for expensive graph-tracing GC, complicates
replication, complicates back-ups, etc.
~ git's weak binding of human-chosen names to revisions
is silly: I don't want to have to use SHA1 strings in
conversation or email but I do want the names I use to
be definitive and secured within the revctl system
~ some variation on NIH syndrome is keeping them away from
mkpatch/dopatch
~ git's logical history graph has the wrong topology
~ git's physical storage of history is needlessly inefficient
and vulnerable to history lacunae
The biggest annoyance is that what we've wound up with is,
essentially, a global transactional P2P distributed filesystem
-- over which people *should* be going apeshit and working out
all kinds of interesting applications. But they aren't and they
don't, which is sad.
-t
- [Gnu-arch-users] git foo,
Thomas Lord <=