[HN Gopher] Version control without Git
___________________________________________________________________
Version control without Git
Author : quickthrower2
Score : 130 points
Date : 2021-09-16 09:27 UTC (1 days ago)
(HTM) web link (itoshkov.github.io)
(TXT) w3m dump (itoshkov.github.io)
| cjwoodall wrote:
| 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
| keynesyoudigit wrote:
| Liked purely for the All Your Base reference.
| smoyer wrote:
| 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....
| fouc wrote:
| > 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
| kk6mrp wrote:
| Did no one here watch the video version?
| kasabali wrote:
| Nobody remembers "The Git Parable"?
|
| https://tom.preston-werner.com/2009/05/19/the-git-parable.ht...
| maybenotafart wrote:
| Congrats! we have gone back to software development pre-1980
| _hilro wrote:
| 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.
| da_chicken wrote:
| > _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?
| detaro wrote:
| > _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".
| compiler-guy wrote:
| Schools were teaching version control long before git.
| ryanianian wrote:
| > 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.
| MrGilbert wrote:
| 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.
| dspillett wrote:
| _> 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 wrote:
| 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 wrote:
| 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.
| [deleted]
| KingOfCoders wrote:
| 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.
| zoomablemind wrote:
| > ...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.
| smcameron wrote:
| 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.
| pfdietz wrote:
| 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 wrote:
| Sadly too young for systems before this VAX!
| martinflack wrote:
| 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 wrote:
| 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.
| tempodox wrote:
| Now we can finally rewrite git ourselves ;)
| sys_64738 wrote:
| You can simulate git via:
|
| mkdir v2 ; cp -rp v1 v2
| makeva wrote:
| Cool now do a git blame
|
| git push? git rebase?
| sys_64738 wrote:
| These are tools you'd need to write atop the version dirs.
| HatchedLake721 wrote:
| So you can't really then simulate git with:
|
| mkdir v2 ; cp -rp v1 v2
|
| can you?
| sys_64738 wrote:
| 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 wrote:
| 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_64738 wrote:
| 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 wrote:
| 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.
| TomMasz wrote:
| 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 wrote:
| disagree, its very useful for individual projects where lots of
| exploration and bouncing around can happen
| thomascgalvin wrote:
| 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.
| coldcode wrote:
| 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 wrote:
| 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 wrote:
| The use of `diff` and `patch` to express merge is something
| interesting that I only learned from reading this article.
| edoceo wrote:
| 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.
| rrauenza wrote:
| Larry Wall is often most known for Perl, but his
| contribution of the patch tool is underrated.
| y4mi wrote:
| While it's admittedly rare, this workflow continues to
| exist to date. The Linux kernel development comes to mind
| as an obvious example.
| MikeTheGreat wrote:
| > 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 :)
| Dolpheyn wrote:
| Can't believe I just got rickrolled from a hackernews post
| harryvederci wrote:
| Glad to see I'm not the only one!
| mapolone wrote:
| 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
| smcameron wrote:
| And if you like both quilt and git, then there's stgit
| https://stacked-git.github.io/
| ihusasmiis wrote:
| I can't believe people spent time doing this and they eventually
| published it.
| recursive wrote:
| So how can you explain the fact that it clearly exists then?
| allannienhuis wrote:
| "I can't believe" isn't meant to be taken literally. It is a
| way of saying "I am astounded".
| harryvederci wrote:
| I am astounded that you actually explained this.
| carterschonwald wrote:
| Am I missing something or why does the author repeatedly misspell
| --recursive as --recusive?
| robaato wrote:
| Interesting, as he manages to spell it correctly in text.
| tempodox wrote:
| File operations that let the command recuse itself from doing
| them? Or just bad copy-pasta.
| chrismorgan wrote:
| 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
___________________________________________________________________
(page generated 2021-09-17 23:02 UTC)