18 ms·

Version control without Git

150 points by quickthrower2 5y ago

fouc 5y 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_64738 5y ago
You can simulate git via: mkdir v2 ; cp -rp v1 v2
- makeva 5y ago
  Cool now do a git blame git push? git rebase?
  - sys_64738 5y ago
    These are tools you'd need to write atop the version dirs.
    - HatchedLake721 5y ago
      So you can't really then simulate git with: mkdir v2 ; cp -rp v1 v2 can you?
      - sys_64738 5y ago
        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.
- LinuxBender 5y 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 https://linux.die.net/man/1/rsnapshot
  - sys_64738 5y 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.
    - kwhitefoot 5y ago
      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.
smoyer 5y 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-Porcelain https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po....
_hilro 5y 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.
- dspillett 5y 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 5y 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.
    - dspillett 5y ago
      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.
      - pwdisswordfish8 5y ago
        > 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.
Dolpheyn 5y ago
Can't believe I just got rickrolled from a hackernews post
- harryvederci 5y ago
  Glad to see I'm not the only one!
- itoshkov 5y ago
  }:-) I was especially careful not to promise a video of the tutorial...
ihusasmiis 5y ago
I can't believe people spent time doing this and they eventually published it.
- recursive 5y ago
  So how can you explain the fact that it clearly exists then?
  - allannienhuis 5y ago
    "I can't believe" isn't meant to be taken literally. It is a way of saying "I am astounded".
    - harryvederci 5y ago
      I am astounded that you actually explained this.
carterschonwald 5y ago
Am I missing something or why does the author repeatedly misspell —recursive as —recusive?
- chrismorgan 5y 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
  - itoshkov 5y ago
    Fixed. Thank you.
- robaato 5y ago
  Interesting, as he manages to spell it correctly in text.
- tempodox 5y ago
  File operations that let the command recuse itself from doing them? Or just bad copy-pasta.
- itoshkov 5y ago
  Because I copy & pasted it :) Thanks for pointing this out.
KingOfCoders 5y 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.
- pfdietz 5y 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.
  - KingOfCoders 5y ago
    Sadly too young for systems before this VAX!
  - martinflack 5y 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...)
    - pfdietz 5y ago
      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.
- zoomablemind 5y 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.
tempodox 5y ago
Now we can finally rewrite git ourselves ;)
mapolone 5y 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 http://savannah.nongnu.org/projects/quilt [2] https://tools.ietf.org/doc/quilt/quilt.html https://tools.ietf.org/doc/quilt/quilt.html
- smcameron 5y ago
  And if you like both quilt and git, then there's stgit https://stacked-git.github.io/ https://stacked-git.github.io/
  - mapolone 5y ago
    Thanks for sharing!
TomMasz 5y 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 5y ago
  disagree, its very useful for individual projects where lots of exploration and bouncing around can happen
- thomascgalvin 5y 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.
- chousuke 5y ago
  Overkill? Git is not overkill for a single file. If it's text and you edit it, use git.
coldcode 5y 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 5y 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 5y ago
  The use of `diff` and `patch` to express merge is something interesting that I only learned from reading this article.
  - edoceo 5y 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.
    - y4mi 5y ago
      While it's admittedly rare, this workflow continues to exist to date. The Linux kernel development comes to mind as an obvious example.
    - rrauenza 5y ago
      Larry Wall is often most known for Perl, but his contribution of the patch tool is underrated.
      - chousuke 5y ago
        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.
cjwoodall 5y 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 5y ago
Congrats! we have gone back to software development pre-1980
kasabali 5y ago
Nobody remembers "The Git Parable"? https://tom.preston-werner.com/2009/05/19/the-git-parable.html https://tom.preston-werner.com/2009/05/19/the-git-parable.ht...
keynesyoudigit 5y ago
Liked purely for the All Your Base reference.
kk6mrp 5y ago
Did no one here watch the video version?
itoshkov 5y 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!).

150 points by quickthrower2 5y ago

fouc 5y 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_64738 5y ago

You can simulate git via: mkdir v2 ; cp -rp v1 v2

makeva 5y ago
Cool now do a git blame git push? git rebase?
- sys_64738 5y ago
  These are tools you'd need to write atop the version dirs.
  - HatchedLake721 5y ago
    So you can't really then simulate git with: mkdir v2 ; cp -rp v1 v2 can you?
    - sys_64738 5y ago
      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.
LinuxBender 5y 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 https://linux.die.net/man/1/rsnapshot
- sys_64738 5y 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.
  - kwhitefoot 5y ago
    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.

smoyer 5y 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-Porcelain https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po....

_hilro 5y 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.

dspillett 5y 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 5y 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.
  - dspillett 5y ago
    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.
    - pwdisswordfish8 5y ago
      > 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.

Dolpheyn 5y ago

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

harryvederci 5y ago
Glad to see I'm not the only one!
itoshkov 5y ago
}:-) I was especially careful not to promise a video of the tutorial...

ihusasmiis 5y ago

I can't believe people spent time doing this and they eventually published it.

recursive 5y ago
So how can you explain the fact that it clearly exists then?
- allannienhuis 5y ago
  "I can't believe" isn't meant to be taken literally. It is a way of saying "I am astounded".
  - harryvederci 5y ago
    I am astounded that you actually explained this.

carterschonwald 5y ago

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

chrismorgan 5y 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
- itoshkov 5y ago
  Fixed. Thank you.
robaato 5y ago
Interesting, as he manages to spell it correctly in text.
tempodox 5y ago
File operations that let the command recuse itself from doing them? Or just bad copy-pasta.
itoshkov 5y ago
Because I copy & pasted it :) Thanks for pointing this out.

KingOfCoders 5y 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.

pfdietz 5y 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.
- KingOfCoders 5y ago
  Sadly too young for systems before this VAX!
- martinflack 5y 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...)
  - pfdietz 5y ago
    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.
zoomablemind 5y 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.

tempodox 5y ago

Now we can finally rewrite git ourselves ;)

mapolone 5y 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 http://savannah.nongnu.org/projects/quilt [2] https://tools.ietf.org/doc/quilt/quilt.html https://tools.ietf.org/doc/quilt/quilt.html

smcameron 5y ago
And if you like both quilt and git, then there's stgit https://stacked-git.github.io/ https://stacked-git.github.io/
- mapolone 5y ago
  Thanks for sharing!

TomMasz 5y 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 5y ago
disagree, its very useful for individual projects where lots of exploration and bouncing around can happen
thomascgalvin 5y 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.
chousuke 5y ago
Overkill? Git is not overkill for a single file. If it's text and you edit it, use git.

coldcode 5y 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 5y 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 5y ago
The use of `diff` and `patch` to express merge is something interesting that I only learned from reading this article.
- edoceo 5y 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.
  - y4mi 5y ago
    While it's admittedly rare, this workflow continues to exist to date. The Linux kernel development comes to mind as an obvious example.
  - rrauenza 5y ago
    Larry Wall is often most known for Perl, but his contribution of the patch tool is underrated.
    - chousuke 5y ago
      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.

cjwoodall 5y 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 5y ago

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

kasabali 5y ago

Nobody remembers "The Git Parable"? https://tom.preston-werner.com/2009/05/19/the-git-parable.html https://tom.preston-werner.com/2009/05/19/the-git-parable.ht...

keynesyoudigit 5y ago

Liked purely for the All Your Base reference.

kk6mrp 5y ago

Did no one here watch the video version?

itoshkov 5y 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!).