> 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.
diff and patch feel like tools that have existed forever. I feels weird to think that someone wrote them instead of them just manifesting fully formed with the first version of UNIX.
> ...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...)
You'd have to violate the standard a bit (version is a positive integer and :newest refers to the largest such in the file system). But I don't know that anyone uses it these days, so maybe that's ok.
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.
Perhaps here it needs a better title. In the actual page the short description comes before that heading.
Not sure what the best answer would be, use the longer text (too long), keep the first significant heading as title (some like yourself find this misleading), or make something up that fits (some may complain of editorialising or just that they think the alternative title is itself wrong in some way).
Or you could look, see it isn't what you want/expect, and move on. It is close enough IMO, not exactly deliberately vague and/or misleading click-bait.
The answer is to not humor people who have unreasonable complaints about things that are their own fault (making assumptions about the content of an article aka judging a book by its cover). The title is fine.
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.
I once made something very similar for myself in College when I was told not to use git for something in a lab… so my solution was to automate making archives. It worked ok. Definitely helped me appreciate git. Now a days i would have just used git and released archives to the rest of the org
I remember back in the 80's and early 90's using a shared file system and discipline for my team to build large Mac apps without one (there were none available). Clearly today no one in their right mind would do this.
I just published the rest of the tutorial. It adds the remote/distributed VCS parts plus fixes some of the mistakes and typos I made. ("recusive"?! the shame!).
There's no question git is overkill for individual projects but it doesn't take long to learn the add/commit/push commands you'll most often use. But there's nothing wrong with wanting to build your own tools.
How is it overkill? I already have it installed on my machine, I already have an account on GitLab/GitHub/Whatever, and I already know the commands I need to do close to 100% of my day to day work.
Are there features of Git that I won't use? Sure. There are also features of IntelliJ that I don't use, but that doesn't make it overkill for my hobby code.
I think a closer example at the filesystem level would be
rsnapshot alpha
rsnapshot [1] uses hard links when it can to create a delta of changed files. Reverting can be done with rsync or cherry picking files. git blame would have to be done via something like auditd and syslog and nowhere near as easy as using git. I use rsnapshot to back up my git repos in the event they get corrupted.
Pretty neat! Could probably make some simple shell scripts from the examples shown, not-git-status, not-git-commit, etc