gnu-arch-users
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]