Version control without Git(itoshkov.github.io)
itoshkov.github.io
Version control without Git
https://itoshkov.github.io/git-tutorial
67 comments
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 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.
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 :)
The use of `diff` and `patch` to express merge is something interesting that I only learned from reading this article.
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.
Larry Wall is often most known for Perl, but his contribution of the patch tool is underrated.
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.
In 1000 years the religion is that Larry Wall invented the computer in three days.
By then Larry will be known as Leibowitz
While it's admittedly rare, this workflow continues to exist to date. The Linux kernel development comes to mind as an obvious example.
Coming from RCS, CVS, SVN to Git, git is a game changer - yes everyone knows that.
But what was astonishing me most was the version system build into the VMS OS file system.
But what was astonishing me most was the version system build into the VMS OS file system.
> ...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.
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.
File versioning was in BBN's TENEX, which evolved into TOPS-20 ("TWENEX") for DEC's DECSYSTEM 20 computers.
File versioning is also part of pathnames in Common Lisp, although it (the versioning, not Common Lisp) is really a fossil at this point.
File versioning is also part of pathnames in Common Lisp, although it (the versioning, not Common Lisp) is really a fossil at this point.
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.
Sadly too young for systems before this VAX!
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.
[1] http://savannah.nongnu.org/projects/quilt
[2] https://tools.ietf.org/doc/quilt/quilt.html
[1] http://savannah.nongnu.org/projects/quilt
[2] https://tools.ietf.org/doc/quilt/quilt.html
And if you like both quilt and git, then there's stgit https://stacked-git.github.io/
Thanks for sharing!
Am I missing something or why does the author repeatedly misspell —recursive as —recusive?
Because I copy & pasted it :) Thanks for pointing this out.
Interesting, as he manages to spell it correctly in text.
File operations that let the command recuse itself from doing them? Or just bad copy-pasta.
Another error: a couple of “repo” that should be “.repo”:
mv ../ProjectX-v0.zip repo/commits/c0.zip
mv ../ProjectX-v1.zip repo/commits/c1.zipFixed. Thank you.
Title is horribly incorrect.
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.
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.
The actual title is "git-tutorial" :) The "Version Control Without Git" is the title of the first section.
But this is my first time using github pages, so I screwed it up.
But this is my first time using github pages, so I screwed it up.
> I expected...
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.
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.
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.
> Not sure what the best answer would be
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 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.
But usually, these go by the line of "We implemented git in [insert favorite language here]". Which is perfectly fine.
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.
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.
> 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?
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?
Schools were teaching version control long before git.
> 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.
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".
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".
[deleted]
Can't believe I just got rickrolled from a hackernews post
}:-)
I was especially careful not to promise a video of the tutorial...
I was especially careful not to promise a video of the tutorial...
Glad to see I'm not the only one!
Nobody remembers "The Git Parable"?
https://tom.preston-werner.com/2009/05/19/the-git-parable.ht...
https://tom.preston-werner.com/2009/05/19/the-git-parable.ht...
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.
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.
disagree, its very useful for individual projects where lots of exploration and bouncing around can happen
Overkill? Git is not overkill for a single file.
If it's text and you edit it, use git.
If it's text and you edit it, use git.
Did no one here watch the video version?
Liked purely for the All Your Base reference.
ihusasmiis(1)
Now we can finally rewrite git ourselves ;)
Congrats! we have gone back to software development pre-1980
You can simulate git via:
mkdir v2 ; cp -rp v1 v2
mkdir v2 ; cp -rp v1 v2
I think a closer example at the filesystem level would be
[1] - https://linux.die.net/man/1/rsnapshot
rsnapshot alpha
[1] - https://linux.die.net/man/1/rsnapshot
Probably rsync is smarter than my cp -rp example.
Folk who are downvoting my original comment really don't understand how git version controls at the atomic level.
Folk who are downvoting my original comment really don't understand how git version controls at the atomic level.
or use cp --recursive --preserve --link so that the copy occupies almost no space. Of course this relies on your editor not editing in place.
Cool now do a git blame
git push? git rebase?
git push? git rebase?
These are tools you'd need to write atop the version dirs.
So you can't really then simulate git with:
mkdir v2 ; cp -rp v1 v2
can you?
mkdir v2 ; cp -rp v1 v2
can you?
The fundamental git model you can. The tools needed are above that in some form such as diff. git does the equivalent. Stop being pedantic.
Pretty neat! Could probably make some simple shell scripts from the examples shown, not-git-status, not-git-commit, etc