> In this tutorial I’ll try to describe how git works, without using git. Instead, we’ll create a simple, git-like system using just zip files, diff, and patch.
Pretty neat! Could probably make some simple shell scripts from the examples shown, not-git-status, not-git-commit, etc
After understanding the content of this blog post, I'd recommend reading the "Internals" chapter of the Git documentation (most of us don't use many of the available "plumbing" commands) - https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po....
I thought this was cute. I (mostly?) “get” git. At least all of what was shown was formerly known to me.
I would have added a section about how keeping the commit numbers straight is a a pain and then demonstrated how we could just index them with a hash (md5sum or similar).
I thought about sharing this tutorial(?) with some of my “git is kinda fuzzy” colleagues, but I realized that they often seem fuzzy in the basic file tree navigation layers and this expose’ relies on a good degree of comfort with “file ops”.
I find that less experienced developers are often less than strong when it comes to basic “file ops” now days. I blame IDEs, black box build tools, etc.
> I find that less experienced developers are often less
> than strong when it comes to basic “file ops” now days.
> I blame IDEs, black box build tools, etc.
Also phones / tablets. Those things do an amazing job of hiding the underlying files from users so nowadays you can use a computer (phone/tablet) without ever needing to even think about files.
And you know what else is wrong about tablets? Well, let me tell you, - wait, hold on, I gotta go shake my cane at some kids on my lawn :)
Wow! Ok, in like 199x and before, folks were sharing fixes by posting diff/patch files on like Usenet and stuff. It was wild. After CVS, SVN now on git, I mean, I have nostalgia but I don't miss it.
> ...version system build into the VMS OS file system.
That was more of "versioning" than "version control" system. It simply automated the sequential numbering of the saved instances of a file. The versions were not deltas, just normal files, the version number being part of file specification:
name.ext;ver
As much as one can do with versions was diff, purge and file operations, basically, no change annotation or higher level grouping. But being files, the versions allowed to see the what-who-when changed. No why. Still this probably was convenient in some use-cases and as an immediate file backup.
As for the real version control system on OpenVMS, one of such was called CMS, part of DECset suite. I believe it was of exclusive-check-out/check-in kind, similar to how it's done with, say, CVS, but absolutely not like CVS otherwise. For example, there was no support for directories in the repository.
I guess these days it may be possible to run Git on OpenVMS too.
CVS was not of the exclusive-check-out/check-in kind, it would merge by default on "cvs update", this was one of the main differences between it and RCS or sccs. The other main difference was it had a network protocol and didn't rely on the filesystem for sharing (e.g. NFS and the like). It was probably this 2nd difference that enabled it, (and subversion), to overtake RCS and sccs in the 90s.
I always wondered if Common Lisp pathname versioning could be leveraged intentionally when pointing at files in a git repo, to reference older versions of that filename. (And whether that gives any utility...)
A long time ago before git I've casually run into quilt[1]. Not really immediate but if you don't like git may be nice to use. On IETF[2] there's a quick tutorial too.
> It's yet another 'let's recreate git from scratch, kinda' post.
I don't think that's what it's doing. It's just trying to explain what git does through analogy and example.
A remarkable number of people never grok that git is basically just a version control repository for source code (checkout/commit) that itself has been checked into a version control repository for VC repositories (pull/push). There's lots of reasons for it doing that, most of which are grounded in the fact that lots of developers only learn just enough VC to satisfy their immediate coworkers, and otherwise treat it like a magic black box.
Did you ever notice that after git became popular that colleges started to teach CS students to use version control? Ever think about why that might be?
> Did you ever notice that after git became popular that colleges started to teach CS students to use version control? Ever think about why that might be?
Because schools have recognized the need to teach some pragmatic tools in addition to pure theory?
I had a "tools" class in undergrad 15 years ago. Learned shell, perl, pcre regexes, make, cvs, subversion, etc. They created the class due to the perception of new-grads being unable to use real-world tools to do real work. Since then, many schools have adopted a similar approach: either a dedicated class or treating many classes as "project"-style classes that use real-world toolsets and SDLCs.
> Did you ever notice that after git became popular that colleges started to teach CS students to use version control?
Not really, no. Theory-focussed ones still might not. Practical ones did already teach Subversion etc. Some teach git by teaching the full logic behind it, others as "here's some basic commands you need, everything else is on you if you want to learn it, you won't need it to pass".
In fairness, it very clearly describes what it is doing in the initial lines: “In this tutorial I’ll try to describe how git works”. So it isn't intending to suggest an alternative for git, but just to show what git does for you and, to an extent, how.
Then why do we have titles at all if people need to read the "initial lines" to know what it's about? I don't see how that's a reason not to just improve the title. Perhaps the problem was that I also felt like this was not what I expected.
The article isn't suggesting using this for anything real. It's just using tools that have existed a long time, like diff and patch, to show some of the concepts of version control.
Readit News
Pretty neat! Could probably make some simple shell scripts from the examples shown, not-git-status, not-git-commit, etc
I would have added a section about how keeping the commit numbers straight is a a pain and then demonstrated how we could just index them with a hash (md5sum or similar).
I thought about sharing this tutorial(?) with some of my “git is kinda fuzzy” colleagues, but I realized that they often seem fuzzy in the basic file tree navigation layers and this expose’ relies on a good degree of comfort with “file ops”.
I find that less experienced developers are often less than strong when it comes to basic “file ops” now days. I blame IDEs, black box build tools, etc.
And you know what else is wrong about tablets? Well, let me tell you, - wait, hold on, I gotta go shake my cane at some kids on my lawn :)
But what was astonishing me most was the version system build into the VMS OS file system.
That was more of "versioning" than "version control" system. It simply automated the sequential numbering of the saved instances of a file. The versions were not deltas, just normal files, the version number being part of file specification:
name.ext;ver
As much as one can do with versions was diff, purge and file operations, basically, no change annotation or higher level grouping. But being files, the versions allowed to see the what-who-when changed. No why. Still this probably was convenient in some use-cases and as an immediate file backup.
As for the real version control system on OpenVMS, one of such was called CMS, part of DECset suite. I believe it was of exclusive-check-out/check-in kind, similar to how it's done with, say, CVS, but absolutely not like CVS otherwise. For example, there was no support for directories in the repository.
I guess these days it may be possible to run Git on OpenVMS too.
File versioning is also part of pathnames in Common Lisp, although it (the versioning, not Common Lisp) is really a fossil at this point.
[1] http://savannah.nongnu.org/projects/quilt
[2] https://tools.ietf.org/doc/quilt/quilt.html
Simulating git would be more appropriate.
I expected this to be a look at other version control systems around today. It's yet another 'let's recreate git from scratch, kinda' post.
I don't think that's what it's doing. It's just trying to explain what git does through analogy and example.
A remarkable number of people never grok that git is basically just a version control repository for source code (checkout/commit) that itself has been checked into a version control repository for VC repositories (pull/push). There's lots of reasons for it doing that, most of which are grounded in the fact that lots of developers only learn just enough VC to satisfy their immediate coworkers, and otherwise treat it like a magic black box.
Did you ever notice that after git became popular that colleges started to teach CS students to use version control? Ever think about why that might be?
Because schools have recognized the need to teach some pragmatic tools in addition to pure theory?
I had a "tools" class in undergrad 15 years ago. Learned shell, perl, pcre regexes, make, cvs, subversion, etc. They created the class due to the perception of new-grads being unable to use real-world tools to do real work. Since then, many schools have adopted a similar approach: either a dedicated class or treating many classes as "project"-style classes that use real-world toolsets and SDLCs.
Not really, no. Theory-focussed ones still might not. Practical ones did already teach Subversion etc. Some teach git by teaching the full logic behind it, others as "here's some basic commands you need, everything else is on you if you want to learn it, you won't need it to pass".
In fairness, it very clearly describes what it is doing in the initial lines: “In this tutorial I’ll try to describe how git works”. So it isn't intending to suggest an alternative for git, but just to show what git does for you and, to an extent, how.
This is more of a "hey, we have these tools on our system and can use them to simulate git". That's somehow different, at least from my pov.
But this is my first time using github pages, so I screwed it up.
Deleted Comment
I was especially careful not to promise a video of the tutorial...