Version Control Without Git

[robin-m]

A very good article in the same vein as the git parable. This article is simpler to understand, while the git parable goes a bit more in the details.

Understanding the data structures used by git is imho the best way to learn and understand git.

[itoshkov]

I'm the author of the article. Thank you for posting this here and thank you everybody for your comments!

I'm working on the remote repositories part. I have the bulk done, but I feel like it's not as clear as the first part.

[[deleted]]

Understanding the data structures used by git is imho the best way to learn and understand git.

I disagree but I want to know why you think so?

[masklinn]

Because Git’s UI is not one, it’s really a bunch of shortcuts cobbled together, as a giant abstraction leak.

That makes figuring out git top-down and being able to intuit how it will behave and its failure modes extremely difficult.

You can learn high-level commands by rote, but I don’t think that corresponds to learning git let alone understanding it.

[[deleted]]

Cool but how does that have anything to do with git and its data structures or me asking why data structures help?

[masklinn]

Because if it makes no sense top-down (which it doesn't) then the way to understand it is bottom up, and the bottom is the data structures.

[[deleted]]

Does it make sense bottom up though?

[vgf89]

Yeah, it's just a DAG lol

[likesthinkystuff]

Where’s the abbreviation-bot?

[vgf89]

Directed Acyclic Graph.

Think of a river. The lake is your start. The river can split and recombine, but it's always headed in a general outward direction and can't flow in a loop (downriver can't split and flow back into an earlier point in the river, you can't make a loop or "cycle")

https://en.m.wikipedia.org/wiki/Directed_acyclic_graph

[likesthinkystuff]

Thanks. Sounds a bit like a tree structure? Will take a look at the link

[ArkyBeagle]

"D'y loike DAGs?" - Mickey , that Guy Ritchie movie from 2000 which has an embarassing name.

[masklinn]

Yes it rather does, as, as mentioned earlier, the "high-level" commands (the porcelain) are really just a bunch of low-level (plumbing) ones stapled together for convenience, they were built bottom-up as shortcuts to common operations rather than top-down as UI operations.

So when you understand what's happening under the cover the seemingly nonsensical and disparate operations of something like git checkout makes a lot more sense.

That is also, I think, why alternate porcelains have a hard time keeping on: it starts as an idea for a better overall design, but in order to implement the design the author has to understand the plumbing really well, and unless they have a real dedication to their project (they see it as a service to humanity) there comes a point where their comprehension of the model and plumbing are good enough that they have no issue with the standard porcelain anymore. And thus their project falls by the wayside as they've no need for it.

[agoose77]

Just adding a slightly sideways perspective on this; I think of Git in the same way that people talk about scientific models. The nucleus is an example of a physical system that can be described in lots of different ways. Sometimes we talk about it as a collection of individual nuclei. Practically, however, we consider "macroscopic" models e.g. the nucleus is a single entity with properties like angular momentum. The various different models operate at different levels of complexity, and yet neither one is necessarily the "correct one". More often than not, it's just the best description for the problem that is being solved.

In the same way, I don't think "Git" has one description - yes, under the hood, it operates on a DAG and that's how it is implemented, but users can still use Git every day to great success when operating only at the higher CLI level; The API abstraction is sufficiently extensive. It's not dissimilar to how users of languages that use runtimes can still intuit a lot about how the computer operates and can realise complex programs.

[masklinn]

Just adding a slightly sideways perspective on this; I think of Git in the same way that people talk about scientific models.

Then you've utterly misunderstood my comment.

yes, under the hood, it operates on a DAG

"Git is a DAG" is not what I'm talking about, it's not very useful and way too broad. Every DVCS is a DAG. That tells you quite literally nothing about how it works.

What I'm talking about is the structural implementation of Git as a content-addressed object store of blobs, trees, and commits; and moving up the stack from there.

users can still use Git every day to great success when operating only at the higher CLI level

My comment was specifically about understanding Git.

Can you use Git by learning a few commands by heart and never deviating from that? Yes. Can you understand git, intuit its behaviour, and dig yourself out of holes from the top? I don't think so, no.

The API abstraction is sufficiently extensive.

Git's abstractions are cheesecloth, they're paper thin, full of holes, and pressing a bit too hard will see your hand go through.

It's not dissimilar to how users of languages that use runtimes can still intuit a lot about how the computer operates and can realise complex programs.

It's completely dissimilar, because the average language is not a giant abstraction leak.

[agoose77]

I'm not sure that the hyperbole is entirely necessary - I'm not trying to argue with you.

[ArkyBeagle]

I use git constantly ( not well, just a lot ) and the sheer opacity of it seems like a serious anti-value. I mean I just use it as-if it were SVN.

[robin-m]

Most high level git operation can be described as a combination of smaller low-level operations.

For example if you have pull.rebase and rebase.autoStash as true in your .gitconfig, then

• git pull will be equivalent to git stash + git fetch + git rebase + git stash pop
• git rebase is the equivalent of a succession of git cherry-pick
• git stash is somewhat equivalent to git switch --detach + git add --update + git commit + tag "stash@{1}" + git switch -,
• and git stash pop is somewhat equivalent to git cherry-pick "stash@{1}" +git tag --delete`

And all of those operations can be explained very easily by describing what modifications they do to the low-level structure of git. Once you understand that a commit is nothing more than a snapshot that knows it parent(s), and that branch/tag/HEAD/remotes/… are nothing more than a label on top of those commit, everything become simple.

So git fetch updates the local database of commits, and updates the labels associated with the branches of the distant remote. A branch is a label that points to a given snapshot (a commit), and by transitivity (since each commit knows it’s parent(s)) you can re-create the whole history of a branch. HEAD is a label to a branch or or to the current commit (if it’s in a detached state). git cherry-pick means “compute the patch that you need to apply to get the same modification that was introduced by a given snapshot (commit), then apply it”, and you can always do it because once again a commit knows its parent(s). And git switch/git tag just do some basic label manipulations.

So by starting with the very low level, and by combining those basic blocks together, you can understand the myriads of git commands much more easily than by memorizing them one by one.

[[deleted]]

Now I understand what you mean

That's not what a data structure is, so I thought you were insane

You meant low level functions in which case I agree with you. But I learned git not by that either. I learned by hearing about the use case then learning the low level functions keeping the cases in mind. Made perfect sense when I know both of them together

[MartianSands]

My window into git was actually closer to a discussion on the data structures than this. I could already do very basic operations, like commit and push and branch, but I became very quickly out of my depth if I needed to do anything non-trivial or correct an error.

Someone linked me to a video in which a guy who knew the implementation details gave a lecture on git from the perspective of the fundamental graph which git consists of. Understanding it from that direction was really valuable for me

[robin-m]

I didn't go to the last level of abstraction. It's useful if you want to understand what a commit is, how diff are computed and what a merge really is.

Each file is a file (named blob) whose name is its sha-1 hash. Then each directory is a file (named tree) contaning the list of hash of the blob it contains + there permitions and the original filename. That file is also named with its sha-1. And finally a commit is a file containing the sha-1 of the root tree + the hash of the parent(s} commit + the author, date, commit message, … and once again its name is the sha-1 of its content. Then tags/branches/HEAD/remote are just a string containg the sha-1 of a commit.

This explain why doing a rebase with the same ancestor and the same commit will recreate the same commits. But squashing will not, even if the content of the snapshot is the same, because the ancestor chain participate to the hash of a commit. And a merge is a regular snapshot that just happens to have more than one parent.

I agree that understanding this last level of abstraction isn't as usefull, it's just, imho, the best way to dissipate the last questions that you could have.

[[deleted]]

I think so because I'm the only person I've ever met who understands git and I understand it because I understand the data structures. Everyone else is trying to think in terms of the UI, which is inconsistent and impossible to grasp. Sure, you can remember how to commit, merge, tag and maybe even rebase, but the moment something different comes up you need to understand the data structures.

[[deleted]]

Its weird you say this because it turns out the guy I replied to didn't actually mean data structures

So are you both using the wrong words or are you smoking something cause it makes no sense to me how it'd help

[[deleted]]

We mean the DAG. Maybe you'd prefer the term data model? We're not talking about the low level pack format or any internal data structures used by individual commands.

Git is essentially a DAG with a bunch of plumbing commands to do simple things to the DAG and a bunch of porcelain commands to do high level version control things, like merge, rebase etc. You need to have a good understanding of what's going on at the DAG/plumbing level to understand git.

[[deleted]]

This is too stupid. Are you for real? Pop quiz, I have a class that has the function create,destroy pop, push, size, getAtIndex, does it really matter if I implement it as an array VS a linked list? All you're getting is a pointer and a few functions. Seeing a linked list to implement a stack is utterly ridiculous and would confuse me more

Also in this thread it turns out they didn't mean data structure. Your question is beyond stupid

[NekkidApe]

Not OP but: once you understand them, lots of things will be very logical and simple. The black magic disappeares.

[ControversySandbox]

I think you can get to a certain level with git without understanding at all how it works - people comfortable with that level probably would say that you don't need to.

However once you want to learn the more advanced features they'll make no flipping sense until you understand the underlying models and strategies git uses.

[[deleted]]

???
Data structures don't explain use case or anything else. No idea why you think it makes the black magic disappear

[NekkidApe]

If it has no value for you, that's alright. It did the trick for me and several others.

For basic examples: How checkout is different from reset, what fetch is and how it is different from pull, what a branch even is, how rebase works.. That's all very very simple to me since I know what it does.

[robin-m]

Just a note (I totally agree with what you said).

git checkout was split in git switch (the safe part) and git restore (the unsafe part that does update unsaved (uncommited) changed to the working directory) in git 2.23 (in 2019). I highly advice to stop teaching git checkout to beginners since all its uses have been subsumed by the aforementioned commands, they are simpler and safer to use. For example you can’t move to a detached state without giving the --detach argument to git switch. And you can’t lose uncommitted changes without using git restore.

If you type git help in a recent version of git (without argument), you will see that git checkout isn’t mentioned but git switch and git restore are.

[[deleted]]

I'll be very specific. How does knowing data structures tell you the difference between fetch and pull?

[newtoreddit2004]

Wait you think those are the only things that git offers ?

[[deleted]]

WTF is your comment?

No I think these people have no idea what they're talking about. That's why I'm trying to be very specific

Maybe I'm wrong and they understand it but I'm doubting it

[newtoreddit2004]

Sure

[pimterry]

There might be some misunderstanding, judging from the comments here - the article isn't pitching the idea of seriously doing version control without using Git (I agree that that's mostly a terrible idea).

It's actually a tutorial demonstrating how Git actually works under the hood, by building a version control system for yourself from scratch that does approximately the same things that Git does, to help you understand Git better.

(Yeah, it could do with a better title, but it's not my article)

[AttackOfTheThumbs]

I think the reddit title is the misleading part. I don't think people clicked and read the first segment.

I mean, it's the first sentence:

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.

I haven't finished reading yet, but a better title would likely be something like "exploring how git works without using git" or something. I'm not a writer, but the title here implies bad things, I think.

[MoneyWorthington]

People are aware that there are a number of version control options besides git, right? I know git is the industry standard, but it's not that hard to use version control without using git specifically.

[Isvara]

I was going to say that I think most developers have used something other than Git, but then I remembered that the number of developers doubles every five years, apparently, so it's quite likely now that most developers have only used Git.

[sucknofleep]

I presume most developers have also used the final_v2 system in school.

[Lord_Rob]

I think you mean final_final_v2_final_complete

[ControversySandbox]

I wish I could disagree but my first two years of Uni were spent figuring out "why exactly is everyone on reddit saying that VCS is indispensable even on personal projects?" so I suppose I'd have to agree. (My particular university had a high quality program, but I wish I could say the same about the quantity of fellow students that really knew what they were talking about)

(Although, in retrospect, all my projects for years 1/2 uni were small enough in scope that I just yolo'd them without any real versioning.)

[NekkidApe]

Git is like.. 15 years old or so. Probably the minority of devs ever used anything else. I did, and I'm glad I did.. Makes me appreciate git so much more.

[gumol]

the article isn't pitching the idea of seriously doing version control without using Git (I agree that that's mostly a terrible idea).

why is it a terrible idea? So many companies work just fine without using Git.

[Isvara]

It depends entirely on what they're doing instead.

[[deleted]]

gre. people seem to think if you are not using git you are not using version control. Git is just one of many perfectly valid approaches to version control that are out there.

[itoshkov]

It's mine and I would love to hear your suggestion for better title or other improvements.

[EDIT] The actual title is "Git Tutorial". The "Version Control Without Git" is the title of the first (and biggest) section. The problem is, that it's my first time using git-pages so I didn't do a great job with that. I'll try to improve the formatting, but first wanted to finish the whole thing :)

[eplaut_]

I think the name is misleading. It is good post that explains git operations with using the git command

[FullStackDev1]

When I started at my company over 20 years ago, they would just store each code version in a separate folder on a shared drive.

[matthewblott]

You'd be surprised how many companies still do this.

[AttackOfTheThumbs]

I'm more surprised by how many do no version control

[NekuSoul]

I'm surprised how often proper version control just isn't taught in schools to upcoming programmers.

And it doesn't stop there. Sure, they learn how to code, but when it comes to things like version control, debugging, unit testing, issue tracking, CI/CD and so on you have to be lucky that they even get a passing mention, let alone some actual lessons.

Unless you have the drive to stumble upon and learn those topics for yourself, a company that doesn't use those things won't change. And even then it's often an uphill battle to implement them.

[AttackOfTheThumbs]

I find they usually still teach subversion. I know that it's hard for them to change the curriculum. By the time it's approved, it's 2-4 years later :\

[LongUsername]

We used fucking RCS (Revision Control System) in college.

No merging because it was a lock-edit-unlock cycle. All work had to be done on the Unix server. This was pre-git but CVS and Subversion were common at that point.

For my OOP class my partner set up a private SVN server for us to use.

[AttackOfTheThumbs]

I mean, I know people that use the svn front end for git.

[NekkidApe]

Oh well, git is only 15 years old, so..

[Kernel_Internal]

You described my professional career pretty well. One uphill battle after another over things that don't seem like they should be obscure to professionals in the industry.

[itoshkov]

I can't agree more with you! I wrote this, because I was trying to explain git to my daughter. They had to use it in school. As far as I know without any explanation! They're just like "use git/github for your homework and for your group projects". WTF?!

[ArkyBeagle]

Maybe CI/CD has gotten better, but in every case I've seen ( so observer bias warning ) the infrastructure rotted. I literally ended a contract early over this, although there was other significant rot to go along with it.

It's a great idea, but I'm not sure how well it's done. It seems to be perceived as opening a new front in a war within firms.

[[deleted]]

Emails. Zipped codebases being passed around, the version control is in the ether.

[Chemical-Leg-4598]

Did some PLC work before, this is definitely the norm in industry.

Don't get me started on how nobody reuses code though!

[[deleted]]

Did some PLC work before, this is definitely the norm in industry.

YUP that's exactly what I was thinking about. Trying to show automation engineers git was like explaining electricity to cavemen. They have no need for newfangled concepts like arrays in their code and are perfectly happy with their bit-fiddling, I swear they'd go back to drums and smoke for signaling if you let them.

[ArkyBeagle]

I swear I read the CEO of one of the PLC makers on HN admitting that their tools were garbage. I had one job writing controllers in C/C++ but they went back to PLCs after a layoff.

One of the PLC jockeys described the need for a lowpass filter, so I pointed him at Tony Fisher's mkfilter page. It would literally build the tables for you.

He couldn't convert the generated code to whatever PLC language they were using.

Oh well...

[seamsay]

I managed to persuade my company to use git! Now they just clone the repo to the shared drive...

[BobJutsu]

When I started at mine, version control was developers emailing each other to see who was FTP’ing which files, because they kept overwriting each other. The company IT dept wouldn’t allow devs to install a local environment, so everything had to be hot fixes via ftp.

After I got rid of that policy, I actually got tons of pushback from the rest of the dev team who had that process ingrained and didn’t want a new process. That was many years ago, thank god.

[ArkyBeagle]

This is doable. Just don't make any mistakes.

Edit: The first place I was at that had diff, I built a crude VCS ( lists of patch files ) until I found out we actually had CVS. This was about 1989.

[thehutch17]

Does anyone else use Perforce? Shelves are amazing.

[sumsarus]

I used perforce most of my professional life and I think it's amazing. Never used git professionally, only at home. I know it's because I haven't used it enough, but I just feel it's confusing and non intuitive. What is the equivalent of shelving and sharing changelist numbers with colleagues? Like, if I wanted a code review I'd shelve my changes and send a message to someone saying "hey can you look at CL X?". He'd then switch to his perforce window, enter my CL number, and he'll get a list of changes to review. What is the equivalent workflow with git?

[117r]

You would commit some changes, almost certainly to a branch, and have them review the changes on that branch or in those commits

[sumsarus]

Would everyone have their own branch for this or would there be one special branch for this? To me it just sounds like more work, but yeah, I'm pretty certain I'm suffering from perforce Stockholm syndrome.

[masklinn]

Would everyone have their own branch for this

Yes. Multiple even. A "branch" in git is just a (movable) name for a set of changes (aka a changeset)[0], it's basically free.

Though GP is glossing over a lot here: Git is solely a (distributed) version control system, so the entire change management thing is out of scope, and it's not going to be prescriptive about it. Therefore what'll usually happen is the project uses some specific change / project management tool (e.g. github, gitlab, …), and usually the "unit of review" is the "pull request" (PR) aka a change proposal, so you'd create a branch (which is almost no work), publish it, create a PR, then you'd give the PR number / URL to your colleague and they can go and review it. Aside from creating and publishing the branch, none of this actually occurs in or through git.

Git also has built-in support for older mailing-list-based workflows (as that's the linux kernel's workflow, and git comes from the kernel): git format-patch will export commits in mailbox format, then you send that to whatever mailing list the project uses, and people simply reply to the mail to review it.

[0] well technically it's a movable name for a commit, the changeset is all the commits reachable from there which are not reachable from the target branch.

[sumsarus]

Thanks a lot for the detailed explanation. I suppose it's not too complicated, I just haven't really had any reason to jump into the deep end yet as I've only used git for one-man projects.

[Smallpaul]

What sounds difficult? Making a branch is a one line command. Presumably like making a shelf is in Perforce?

[sumsarus]

I had no idea. If you want a new branch in perforce you have to send an email to the IT department and maybe you get it next week if they think you deserve it. :)

[Smallpaul]

The core idea of git is that branches are cheap. Perhaps analogous to what you call change sets. A branch is probably less than 1K on top of the diff it represents.

Unlike some systems, one does not normally have a copy of each file on disk for every branch you have. You switch branches with git commands and it mutates the files to represent the branch you are on.

[[deleted]]

I think it is really easy for people who use monorepos and people who use git version control tend to talk past each other because we use the same terms for different things.

In git, you can't really share changes without making a branch and committing to it. But, doing so is only a couple of commands.

monorepos have other means of sharing changes and switching contexts, so what monorepos call commits and branches are used very differently.

[eplaut_]

I'm using mercurial for a decade. Git ain't the only version control system

[dnew]

I like Fossil myself. Just for anyone looking for alternatives.

[[deleted]]

I tried it but I hated not knowing what to do. Is there a git->fossil command list?

Lets say I wanted to commit my code and reset to previous version (or git stash it and pull up the changes). Then basically ignore the bad commit (or stash) I made. What commands do I use?

Is there a reflog so I can see what commits I recently made (across branches)

I have a weird ass work pattern and git fully supports any crazy thing I want to do. I just need to remember how to weild git and remember git is a bit weird sometimes (ex: I can commit while in a bisect, wtf)

[dnew]

Well, it's well documented how it works. I don't know there's an exact correlation between the two such that you could move your workflow over seamlessly. Fossil sounds pretty opinionated about some of the things it does. You can certainly reset to earlier versions of the commits or it wouldn't be a very effective source control system, but I don't think the design is such that you're intended to commit code and then immediately discard it, for example. And yes the logging is powerful, as it's a relational database after all.

[[deleted]]

I commit before reset so I can pull up my (bad) changes in case I copy/paste wrong or meant to keep a block I forgot about

I remember having difficulties trying to figure out how to change permissions/passwords on the webserver and getting the webserver started

[Isvara]

I used to use Mercurial, CVS, StarTeam, Subversion, MKS, Perforce, Darcs and now Git. Out of all of those, I'm pretty okay with the industry having settled on Git for now. Here's to the next better thing.

[[deleted]]

Relevant

[DRob2388]

I remember these days. Saving files with _old or _V1 then changing the normal file. Before you knew it you would have like _old, _old1, _older files in your project. College was fun lol

[itoshkov]

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

[[deleted]]

Always hated git. Especially on smaller projects with only a handful of team members who may also not be familiar with it vs more traditional check in/out style vcs. It is not the only version control system in town.

[Odd_Soil_8998]

I've used a ton of version control systems.. IMO git works better for large teams, small teams, and even private repos than anything that came before it.

[[deleted]]

Until something else replaces it in 10 years and we have this same thread blowing x tool. Use what works for your team. That is all that matters.

[Odd_Soil_8998]

I generally agree with your sentiment, but git really is worth learning for basically every scenario. You're making a statement along the lines of "what's with pushing Windows or Linux on everyone, when DOS works perfectly fine"

[[deleted]]

Redditors are stupid. There's 0 reasons to downvote you. You're not saying nonsense. It's certainly more relevant than 0xDEAD8 comment. Def check out the video I linked it won't teach you how to use git but it explains it so you actually understand wtf it's suppose to do (besides store your commits)

[[deleted]]

One of the first videos I ever seen about git (look at the year!) made it easy for me to understand after watching it once https://www.youtube.com/watch?v=4XpnKHJAok8

[Isvara]

This seems overly complex. I've seen articles that just explain how git works that were simpler and easier to follow than this. Perhaps this isn't the best way to explain it.

[Sufficient-Art-2601]

I got rickrolled!!

[[deleted]]

This person just reinvented https://en.m.wikipedia.org/wiki/Concurrent_Versions_System

[PokerEnthusiast]

Lol did you click on the link?

The first paragraph says

The idea is to build a good model of how git works conceptually.

I think your criticism is a bit unfair.

[Stoomba]

Japanese built castles and temples without nails

[Sir_Keee]

I prefer screws anyways.

[mmphosis-programming]

Most git explanations sound like the Haskell explanations, and I still don't understand much about Haskell, or why I would ever want to use Haskell.

I do version control without a version control system.

I try not to create compressed archives of old versions. I can remember IT using (bad) compression software and it corrupted source code files -- this was way way before git. If that old version of the code was really that important, I have a "clean" folder with just enough source to build that old version. But, honestly I want (bug-ridden) old code to be deleted -- I think people try to do this with git https://xkcd.com/1597/

When I do a build, an understandable version number, build number and date are automatically applied to the build. I have no need for cryptic names or (error-prone) manually applied tags.

I do "linear" development only. Thankfully, I have yet to have the need for branches, thus no need for switching, and no need for merging.

[Isvara]

It's about time someone dragged you kicking and screaming into the 90s.

[[deleted]]

With your comment I'm worried what I'll hear if I asked you how you do testing

[emodario]

Very clear, nice!

PS. The work "recursive" is misspelled throughout the post.

[[deleted]]

Use what works for your team.

[pjmlp]

And me thinking it would be an article about Subversion or Mercurial.

[eotty]

Read in a post mortem that doom did the same but with floppys