Version control without Git

https://itoshkov.github.io/git-tutorial

by quickthrower2 • 5 years ago

150 62 5 years ago

itoshkov.github.io

fouc• 5 years ago

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

sys_647384• 5 years ago

You can simulate git via:

mkdir v2 ; cp -rp v1 v2

makeva• 5 years ago

Cool now do a git blame

git push? git rebase?

sys_647384• 5 years ago

These are tools you'd need to write atop the version dirs.

LinuxBender• 5 years ago

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.

[1] https://linux.die.net/man/1/rsnapshot

sys_647384• 5 years ago

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.

smoyer• 5 years ago

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....

_hilro• 5 years ago

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.

dspillett2• 5 years ago

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.

lucb1e• 5 years ago

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.

tyingq• 5 years ago

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.

MrGilbert• 5 years ago

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.

da_chicken• 5 years ago

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?

compiler-guy• 5 years ago

Schools were teaching version control long before git.

ryanianian• 5 years ago

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.

detaro• 5 years ago

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".

itoshkov5• 5 years ago

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.

Dolpheyn• 5 years ago

Can't believe I just got rickrolled from a hackernews post

harryvederci• 5 years ago

Glad to see I'm not the only one!

itoshkov5• 5 years ago

}:-)

I was especially careful not to promise a video of the tutorial...

carterschonwald• 5 years ago

Am I missing something or why does the author repeatedly misspell —recursive as —recusive?

robaato• 5 years ago

Interesting, as he manages to spell it correctly in text.

tempodox2• 5 years ago

File operations that let the command recuse itself from doing them? Or just bad copy-pasta.

chrismorgan• 5 years ago

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.zip

itoshkov5• 5 years ago

Fixed. Thank you.

itoshkov5• 5 years ago

Because I copy & pasted it :) Thanks for pointing this out.

KingOfCoders2• 5 years ago

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.

pfdietz2• 5 years ago

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.

KingOfCoders2• 5 years ago

Sadly too young for systems before this VAX!

martinflack• 5 years ago

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...)

zoomablemind• 5 years ago

...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.

smcameron2• 5 years ago

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.

tempodox2• 5 years ago

Now we can finally rewrite git ourselves ;)

mapolone2• 5 years ago

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

smcameron2• 5 years ago

And if you like both quilt and git, then there's stgit https://stacked-git.github.io/

mapolone2• 5 years ago

Thanks for sharing!

TomMasz• 5 years ago

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.

sitzkrieg• 5 years ago

disagree, its very useful for individual projects where lots of exploration and bouncing around can happen

thomascgalvin• 5 years ago

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.

chousuke2• 5 years ago

Overkill? Git is not overkill for a single file.

If it's text and you edit it, use git.

coldcode• 5 years ago

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.

travisgriggs• 5 years ago

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.

ogogmad• 5 years ago

The use of `diff` and `patch` to express merge is something interesting that I only learned from reading this article.

edoceo2• 5 years ago

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.

MikeTheGreat• 5 years ago

    > 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 :)

cjwoodall• 5 years ago

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

maybenotafart• 5 years ago

Congrats! we have gone back to software development pre-1980

kasabali• 5 years ago

Nobody remembers "The Git Parable"?

https://tom.preston-werner.com/2009/05/19/the-git-parable.ht...

keynesyoudigit• 5 years ago

Liked purely for the All Your Base reference.

kk6mrp• 5 years ago

Did no one here watch the video version?

itoshkov5• 5 years ago

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!).

Version control without Git

Related Stories