Hi, a couple of extra comments about the theme.
On 03/11/2019 00:01, Michael wrote:
+1.
On 2019-11-01, at 12:39 PM, likejudo <anil.r...@gmail.com
<mailto:anil.r...@gmail.com>> wrote:
I was wondering if this isn't space inefficient - and how does it
become superior to a VCS by storing snapshots rather than deltas?
Initially Git is space inefficient as the first step is simply to just
zlib compress each and every file in the new snapshot. However if the
object id Hash value is identical (nothing changed!) then there is
nothing new to store - instant de-duplication. But if it did change,
hmm, then we do get a whole new object.
But that Torvalds guy was sneaky, and so (third step) he knew that the
new and old files were mostly identical, often with common text even
across other files, so he create the pack compression mechanism which
records **similarity** (old version is current version from start to
point A, and from point B to the end, you'd inserted texted between A
and B. i.e. the diff will be A-B). Hence ... [Michael's good points]
Some people will cite studies showing that the pack files have better
compression than you'd normally expect; this is to be expected from
compressing a larger amount of data.
Some people will cite that "unmodified files checkedsummed" prevent
unexpected alterations; git is actually the first example I know of of
a block-chain in real life, before it was called a block chain. Git
gains all the advantages of blockchains for detecting accuracy.
all true.
What I think is the success of Git, which is implicit in the way Linux
development works, is that "Control" [aka managers from hell] has been
*distributed* from the management to the user. You no longer need any
permission to store anything you want into the holy shrine of the the
"VCS" (in case you might have somehow contaminated it).
The manager is relieved of those horrid tasks of handling coders, and
simply lists the valid hash of the "correct" versions. All your nif naff
and trivia are local to you, but are secure, and validated by their own
hashes. You can get back to the various interim states you were at
without worry.
The critical point here (and this is slightly philosophical) is that
there is no longer a single MASTER (see works of art such as Mona Lisa,
or your code..) Code can be perfectly replicated at almost zero cost.
It's value is in having the correct copy (the hash), rather than having
the only copy. The whole version "Control" paradigm has broken out of
the 'fragility' box that bedevilled physical artefact control (paper
drawings, serialised parts, VIN numbers on cars).
Having broken the veracity problem, the diff based approach with a
central authority falls away, especially when the pack file technique is
included.
There is still the problem of non-diffable files (e.g. audio/video (AV)
edits) where it is still an all or nothing problem (especially for
packing), but that is an issue common to both approaches. The Microsoft
contributors are looking at how they can handle the Windows mono-repo
(largest in the world!), and then hopefully others will look at the
large mono-file problems (how to diff and merge AV files)
Some people will question what "superior" means.
The bottom line is this: Git was developed for the linux kernel. Git
was developed based on the needs of a decently sized small project.
Yea, there was a time when I thought linux was big. "Big" is what you
get when Microsoft and Google both start moving their
development/version control over to git. There's stuff in git designed
to deal with very, very large archives that these two have contributed.
In a nutshell, git has these advantages over everything else that came
before it:
1. Ability to work with really large archives.
2. Ability to recover not just a version of a file, but a version of a
project, even as filenames change
3. Ability to check what changes were made in a given subdirectory
during a period of time -- used by people working on a subset of the
linux kernel, for example.
4. Ability to merge more than two deltas off a previous base
5. Ability to ensure no one slipped unauthorized changes into the
source code.
6. Ability to have different people work on different files at the
same time without ever running into "locking" issues, without having
to have a network connection at "checkout" time, without needing to
have a concept of checking out.
7. Ability to consider anyone's copy as the "master" copy -- useful if
the maintain/"master" of a project changes.
When you consider these goals, space used by text files isn't nearly
as important. Once you get to something the size of the linux code
base, you can start to think that you might be consuming disk space.
====
As stated, the best way to think of git is a read-only filesystem.
Files are presented to git in their "only" finished form, and do not
get stored in the filesystem until finished. There is no
"differential" at the lowest level, only a bunch of full files that do
not change.
Personally I don't use the read-only filesystem metaphor as it doesn't
quite work for me, but I can see that it is a useful analogy (I'd get
hung up on the decision about which files are journaled in Git or not)
Everything else is layered on top of that.
The files are named by their hash code.
There are files that contain mappings of file user-names to hash codes
-- which in turn have a hash code name. These are the "directory
listings". Some of those files are sub-directories instead of
user-supplied files.
There are files that contain the hash of the top-level project
directory, and information about which version that project directory
has represents.
What does this not give you, that has to be calculated all the time?
The diff from version N to N+1. When you want to apply "what changed"
between C and D as a rebase onto B.
Diff-based VCS's give you that cheaply, but lose all the other benefits.
Linux found those benefits to be better.
Microsoft and Google are switching.
Are there issues/problems? Sure.
Are they less of an issue this way than any other way so far? Seems
like it.
Are there features people would like to see in Git? Yep.
Could most of them be added to git without changing the "Read only
filesystem" at the heart? Yes.
Is there a better system design than git? Sure. Do we know what it is?
Probably not.
--
Philip
--
You received this message because you are subscribed to the Google Groups "Git for
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/git-users/22a03422-3bd3-cca3-a069-da1536894f5c%40iee.email.
