7 ms·

“Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.” — Isaac Wolkerstorfer http:

“Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.” — Isaac Wolkerstorfer http://twitter.com/agnoster/status/44636629423497217 http://twitter.com/agnoster/status/44636629423497217

auggierose 6y ago
What Hilbert space would that be?
- naringas 6y ago
  I am not sure, but I think it's a Joke Hilbert space
  - HelloNurse 6y ago
    There's also very little in a graph of changes and revisions that could be considered a manifold, which makes looking for homeomorphic endofunctors pointless. But the first impression is strong, it's still a good joke.
bollu 6y ago
While the above is tecnobabble, there /is/ a simple way to state what git is. It's an API to interact with a torsor. We have files, which are inert objects and form a "file space". We have diffs. Diffs can "act" on a file to produce a new file or a conflict --- we call this as "applying a patch". Mathematicians would call it a "group(oid) action". Diffs are a groupoid because (1) there's an identity diff that does nothing, (2) diffs can be smashed together, (3) if the smashing of diffs succeeds, the operation of concatenation is associative, (4) all diffs are invertible. If we were to delete added lines and add the deleted lines, this inverts the diff. Finally, we have a rooted DAG where each node is a diff, and the root is the empty diff. Git queries enable to manipulate paths in the DAG, which corresponds to smashing together diffs along a path to produce a file. If one groks this, the rest of git is a pretty poor interface on top of this nice mathematical structure. For more physics-y applications of torsors, check out the baez article: https://math.ucr.edu/home/baez/torsors.html https://math.ucr.edu/home/baez/torsors.html
- zitterbewegung 6y ago
  What do you think of darcs?
- matthiasv 6y ago
  While this sounds all nice it actually fails to model Git as it is. Git is an object database and its objects are blobs, trees and commits not diffs, so your premise is based on a misconception.
  - thaumasiotes 6y ago
    > Git is an object database and its objects are blobs, trees and commits not diffs What do you think is the difference between a "commit" and a "diff"?
    - detaro 6y ago
      A "commit" doesn't contain a diff, it contains (references to) the blobs of the files at that state. Diffs are display-only, generated by comparing two full file states.
      - thaumasiotes 6y ago
        You really believe that git stores -- in full -- every version of a tracked file? Every commit that deletes the whitespace from an otherwise empty line in a 30KB file is another 30KB of hard drive space gone?
        detaro 6y ago
        The git book explains the internals very well, so you can easily verify it for yourself. Files are referenced as objects in trees, which are pointed to by commits. editing a file creates a new object for it. (edited for tone)
        thaumasiotes 6y ago
teekert 6y ago
This would have been funny if indeed it would not have been technobabble.
LgWoodenBadger 6y ago
Seems like an obvious play on "a monad is a monoid in the category of endofunctors, what's the problem?"
- patrickthebold 6y ago
  But the monad one is true, so this particular joke falls a bit flat since it's just nonsense. (I think...)
cmiles74 6y ago
This is funny but I think it strikes at a real truth: what Git is trying to do is legitimately difficult. I can see where the author of the article is coming from and I agree that Git has a lot of commands and it's hard to pull it all together, especially if you are new. And I agree that these commands could be better organized and presented and I think that's something the project is actively trying to address. But isn't the core idea of Git, everyone has their own repository and they share branches, kind of complicated and tricky? In my experience the developers I see having problems with Git are having trouble with the hard stuff, not the easy bits like committing and pushing a change.
- Espressosaurus 6y ago
  Mercurial shows that it's possible to hide much of that complexity behind a user interface that only exposes as much of that complexity as necessary. Git's--and Mercurial's--secret sauce is the directed acyclic graph of commits. Everything else is window dressing. It's complicated if you're used to a linear sequence of commits, but it's not too hard once you grasp the tree structure. All operations are operations that manipulate (or share) the DAG, so it now becomes a matter of mapping how you want to manipulate the DAG onto the command set the tool gives you. Git's toolset was designed by a dozen madmen that didn't talk to each other, so it's a loosely connected set of tools with conflicting syntax and meaning. Mercurial's toolset was designed to be used, so if you know the right terminology, you can easily figure out what command to write. Want to commit something? It's probably hg commit. Want to rebase? It's probably hg rebase. Etc. Git exposes unnecessary complexity. But it won the DVCS popularity contest, so we're stuck with it. I wish something else had won. Oh well...
yencabulator 6y ago
git is a fast, content-addressable, decentralized and symmetrically ad hoc synchronizable, cryptographically verified filesystem, stored as a directed acyclic graph of tags, commits, trees and blobs, in that order, with SHA-1 pointers as edges, backed by a POSIX filesystem, with both a simple storage format and a space- and seek-efficient, compressed delta chained pack format.

auggierose 6y ago

What Hilbert space would that be?

naringas 6y ago
I am not sure, but I think it's a Joke Hilbert space
- HelloNurse 6y ago
  There's also very little in a graph of changes and revisions that could be considered a manifold, which makes looking for homeomorphic endofunctors pointless. But the first impression is strong, it's still a good joke.

bollu 6y ago

While the above is tecnobabble, there /is/ a simple way to state what git is. It's an API to interact with a torsor. We have files, which are inert objects and form a "file space". We have diffs. Diffs can "act" on a file to produce a new file or a conflict --- we call this as "applying a patch". Mathematicians would call it a "group(oid) action". Diffs are a groupoid because (1) there's an identity diff that does nothing, (2) diffs can be smashed together, (3) if the smashing of diffs succeeds, the operation of concatenation is associative, (4) all diffs are invertible. If we were to delete added lines and add the deleted lines, this inverts the diff. Finally, we have a rooted DAG where each node is a diff, and the root is the empty diff. Git queries enable to manipulate paths in the DAG, which corresponds to smashing together diffs along a path to produce a file. If one groks this, the rest of git is a pretty poor interface on top of this nice mathematical structure. For more physics-y applications of torsors, check out the baez article: https://math.ucr.edu/home/baez/torsors.html https://math.ucr.edu/home/baez/torsors.html

zitterbewegung 6y ago
What do you think of darcs?
matthiasv 6y ago
While this sounds all nice it actually fails to model Git as it is. Git is an object database and its objects are blobs, trees and commits not diffs, so your premise is based on a misconception.
- thaumasiotes 6y ago
  > Git is an object database and its objects are blobs, trees and commits not diffs What do you think is the difference between a "commit" and a "diff"?
  - detaro 6y ago
    A "commit" doesn't contain a diff, it contains (references to) the blobs of the files at that state. Diffs are display-only, generated by comparing two full file states.
    - thaumasiotes 6y ago
      You really believe that git stores -- in full -- every version of a tracked file? Every commit that deletes the whitespace from an otherwise empty line in a 30KB file is another 30KB of hard drive space gone?
      - detaro 6y ago
        The git book explains the internals very well, so you can easily verify it for yourself. Files are referenced as objects in trees, which are pointed to by commits. editing a file creates a new object for it. (edited for tone)
        thaumasiotes 6y ago

teekert 6y ago

This would have been funny if indeed it would not have been technobabble.

LgWoodenBadger 6y ago

Seems like an obvious play on "a monad is a monoid in the category of endofunctors, what's the problem?"

patrickthebold 6y ago
But the monad one is true, so this particular joke falls a bit flat since it's just nonsense. (I think...)

cmiles74 6y ago

This is funny but I think it strikes at a real truth: what Git is trying to do is legitimately difficult. I can see where the author of the article is coming from and I agree that Git has a lot of commands and it's hard to pull it all together, especially if you are new. And I agree that these commands could be better organized and presented and I think that's something the project is actively trying to address. But isn't the core idea of Git, everyone has their own repository and they share branches, kind of complicated and tricky? In my experience the developers I see having problems with Git are having trouble with the hard stuff, not the easy bits like committing and pushing a change.

Espressosaurus 6y ago
Mercurial shows that it's possible to hide much of that complexity behind a user interface that only exposes as much of that complexity as necessary. Git's--and Mercurial's--secret sauce is the directed acyclic graph of commits. Everything else is window dressing. It's complicated if you're used to a linear sequence of commits, but it's not too hard once you grasp the tree structure. All operations are operations that manipulate (or share) the DAG, so it now becomes a matter of mapping how you want to manipulate the DAG onto the command set the tool gives you. Git's toolset was designed by a dozen madmen that didn't talk to each other, so it's a loosely connected set of tools with conflicting syntax and meaning. Mercurial's toolset was designed to be used, so if you know the right terminology, you can easily figure out what command to write. Want to commit something? It's probably hg commit. Want to rebase? It's probably hg rebase. Etc. Git exposes unnecessary complexity. But it won the DVCS popularity contest, so we're stuck with it. I wish something else had won. Oh well...

yencabulator 6y ago

git is a fast, content-addressable, decentralized and symmetrically ad hoc synchronizable, cryptographically verified filesystem, stored as a directed acyclic graph of tags, commits, trees and blobs, in that order, with SHA-1 pointers as edges, backed by a POSIX filesystem, with both a simple storage format and a space- and seek-efficient, compressed delta chained pack format.