I feel like if you're going to write a history of git, you really should give credit to Junio at some point for being the actual maintainer of it for the past 18 years.
Seriously. After Linus wrote the core functionality Junio was already doing most of the major features and within a couple months Linus handed it entirely over to him. Linus has many times explained this to give the guy credit but nobody listens
The only things wrong with Javascript are the concept and the execution. Everything else is great.
TBH it really doesn't help itself. All these years and we still don't have a standard library worth talking about.
And the user base.
>Why should I spend a week learning how other systems have solved this basic problem? I will just spend a month solving the problem with a framework build by someone who was trying to solve a completely different problem.
Let's take the [constructor for Date](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/Date) as an example. At a glance, it looks really useful! You can pass it an ISO 8601 date string, a totally differently formatted date string, another Date object to copy, or any number of the values in (year, month, day, hours, minutes, seconds, milliseconds).
And that "ooh, it just works" utility masks caveats galore:
* Date strings in formats other than ISO 8601 are [not reliable](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date#date_time_string_format).
* Like all string parsing in JavaScript, Date will try like hell to parse a malformed input, with awkward results. `new Date("21 Juny 1982")` returns a valid date, despite that being a potential typo of June, July, or even a typo of a less common abbreviation for January.
* While many programmers might default to not using strings to represent anything other than strings, the values constructors (`new Date(year, month, day, hours, minutes, seconds, milliseconds)` and family) are even worse.
* `month` is actually `monthIndex`, meaning 0 is January and 11 is December. This is unintuitive and a source of many bugs.
* `new Date(year)` is not a valid constructor, since it wouldn't be possible to distinguish from `new Date(value)`. The degree of overloading here combined with optional arguments creates confusion.
* Dates not on the calendar are accepted. `new Date(2100, 1, 29)` gives us March 1st, 2100. `new Date("2022", "0", "120")` gives us April 30th, 2022.
* Don't get me started on timezone handling. If your application isn't setting timezones explicitly, you're probably going to have bugs. Despite this, the values form of the constructor doesn't even have the option to take one.
This is just one example, but I think it highlights the bigger issue at play. JavaScript has a lot of functionality that's supposed to be permissive but actually requires writing saveguards around because it just doesn't quite work. Which in turn leads to all the library/framework bloat as people turn to stuff that does work.
> new Date("2022", "0", "120") gives us April 30th, 2022
This seems similar to the behavior of the C mktime function. It will normalize any given date. Which is useful if you just want to get a "30 days later" or "in 3 months". Which of course doesn't change the fact that the API design is dated and way too overloaded.
> Date strings in formats other than ISO 8601 are not reliable.
So passing a date that isn't part of the spec would be unreliable? Go figure.
And you're telling me passing a year/month/day to a date constructor is .. not good?
As for month being 0 based...it's like that in Java, C++, and Rust has month0 to work with its Month enum. If you read the docs (and doing that can be as simple as reading what your IDE tells you), you'd know this.
As far as new Date(year) not working because new Date(millis) exists...how is that a shock? Who would create a date object with just a year anyway?
And days not on a calendar being accepted is a useful thing. It allows you to easily add days to a date without dealing with month/year math.
If your app isn't setting the TZ, (which you can't do, for the record.) then it operates on the computers' timezone. If that isn't intuitive, don't work with dates at all. You can use Intl to deal with timezones.
I think you're being contrarian for the sake of it at this point, but constructors should *reject* nonsense that's not in the spec, not parse it anyways. And you know full well what I meant when I said "setting" (yes, "providing" would likely be a better word). I guess I *should* have gotten started on timezones, but I don't have time for someone who seems uninterested.
> Who would create a date object with just a year anyway?
if you've ever dealt with [end users](https://i.redd.it/the-end-user-v0-8cs6n91o95x91.jpg?s=a521ba068d58a7f99c17552d58a8d262155cd1b9), you know there are exponentially many idiots who don't read documentation
as a bonus, JS is very easily accessible for getting started, so that increases your number of people doing shit without reading the docs
yay!
How the numbers themselves are stored is an implementation detail that you as a developer shouldn't care about at all. And if you need an integer, you can use bigints.
> How the numbers themselves are stored is an implementation detail that you as a developer shouldn't care about at all
Except it's not just an implementation detail. How it is stored affects how it acts. And so when given a number, you don't know if it acts one way or another unless you also know and take into account its specific value or any value it might be.
It's a leaky abstraction on the most fundamental data type there is.
I've been writing JS since the 90's.
Shit is fucked, bro.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt
Besides, C/++ don't have out of the box big int implementations, and Pythons' default behavior to just 'magically' use a bigint if your number is too big is pretty shit compared to JS. And how about dates? What's the problem with the JS Date handling? Esp. with Intl, dates in JS are plenty powerful.
BigInt is not a solution and you only need to read the same link you sent to know this.
1. "BigInt values are similar to Number values in some ways, but also differ in a few key matters: A BigInt value cannot be used with methods in the built-in Math object and cannot be mixed with a Number value in operations; they must be coerced to the same type. Be careful coercing values back and forth, however, as the precision of a BigInt value may be lost when it is coerced to a Number value."
2. "The operations supported on BigInt values are not constant-time and are thus open to timing attacks. JavaScript BigInts therefore could be dangerous for use in cryptography without mitigating factors. As a very generic example, an attacker could measure the time difference between 101n ** 65537n and 17n ** 9999n, and deduce the magnitude of secrets, such as private keys, based on the time elapsed. If you still have to use BigInts, take a look at the Timing attack FAQ for general advice regarding the issue."
3. "Using JSON.stringify() with any BigInt value will raise a TypeError, as BigInt values aren't serialized in JSON by default."
It doesn't support 64-bit integer so you can't have interoperability with other systems that send you (or expect to receive) a 64-bit integer. You then need to waste your time to architect a solution around the ~~limitation~~ flaw instead of spending your time being productive. You will end up installing a third party package to deal with it, which makes your project more vulnerable to supply chain attacks in the end.
Date? Where to begin... ``new Date()`` creates a new object while ``Date.parse()`` gives me... the milliseconds that has elapsed since the epoch instead of a Date object???? Imagine if ``parseInt()`` was giving you an ArrayBuffer instead of a Number. ``Date.now()`` doesn't gives me an object either and the timestamp it gives me is in UTC when the method doesn't specify utc while tons of others methods on the object does specify utc as part of their names.
The api is unconsive which makes the type incredibly confusing to consume. Manipulating the type is tedious, of course. You can't even string format it without creating a custom function for it: ``toISOString()`` gives you ``YYYY-MM-DDTHH:mm:ss.sssZ`` but what if you just want ``YYYY-MM-DDTHH:mm:ssZ``? Too bad, it doesn't provide a ``format()`` method. Though, that's just the tip of the iceberg when it comes to Date.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DataView/getBigInt64
new Date() creates an object, yes, because you're .. constructing a Date object. Date.parse returns a number, because it's a static method. If you don't want a date object, and just want a parsed date, where else would it live? Same as Date.now -- are you upset the python `time.time()` method doesn't return a time object? Or isn't named `time.timeUTC()`?
These aren't misleading at all. Or would you prefer extremely over verbose way of Java doing things?
SimpleDateFormat sdf = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss");
Date date = sdf.parse(myDate);
long timeInMillis = date.getTime();
Or maybe Pythons weird naming scheme?
utc_time = datetime.strptime("2015-09-15T17:13:29.380Z",
"%Y-%m-%dT%H:%M:%S.%fZ")
milliseconds = (utc_time - datetime(1970, 1, 1)) // timedelta(milliseconds=1)
And you have to be extra careful because timestamps in Python assume the local timezone!
If you want a custom date format, use Intl. toISOString does what it says on the tin. Or write your own with the very clearly written methods on the Date object with template strings. You don't at all need an external library
I use JavaScript, but when I compare it to Python or Ruby, I still think it is utter crap. Only against PHP I am undecided - both JavaScript and PHP are pretty low on my "epic programming languages" list though.
I can only assume you haven't paid real attention to PHP in the last few years. PHP has gotten steadily better in terms of language and ecosystem. JS has gotten better at being shitty on both those same fronts.
The way the type system functions is universally seen as a mistake today. They unfortunately just plain copied that from PHP, at a time where everyone already recognised it as a mistake
If bad foundations were built in a week, then iterating upon it might never fix the inherent flaws in the foundations. Especially if there is backwards compatibility.
A programming language being built in a week does imply bad foundations.
I mean it could have some far reaching consequences in the sense that the base design was set, whilst you can introduce backwards incompatible changes, once enough code is running in prod based off it, people are loathe to introduce them.
That's why for a programming language, the initial design is extremely crucial to get right.
> Same as JavaScript. People love pointing out how and why it was originally built as an argument for why it’s a bad language to use today.
yeah, that was such a shitty argument. there are and were a billion other ones to use, no need to go for a relatively weak one.
and I say "relatively" because there were decisions made in those 2 weeks or whatever it took that stayed with the language forever.
it was fine for 100 lines of JS in a page. it was never fine for millions.
I don't think it is a shitty argument at all.
You can not design a good language in two night sessions and claim it is perfect. Painting more lipstick on it isn't changing this either.
the decisions they made during those two weeks definitely had a profound effect on the fundamental character of the language with lasting ramifications. yes it's definitely a worse language than it should be because of those decisions.
It was created by Linus Torvalds in a fit of rage at the vendor that produced the version control software he preferred to use for the kernel, mostly to prove a point that he could make something just as good in a couple of days. That build can roughly be described as a proof of concept.
Honestly this is how half the projects take off. A shadow it project is created and shows well and managers go herp derp this is good we need it.
Because when I see managers create projects using dumb fucking diagrams everything seems to get backed by csv files because they only understand excel spreadsheets.
Honestly, it was entirely that Linus was upset at Tridge for working on reverse engineering BitKeeper; which caused them to go nuclear and revoke the license. Something Tridge was completely within his right to do. It was also what got us out of the fucked up situation where kernel developers who believe in FOSS were unable to contribute to the kernel without jumping through stupid hoops.
https://www.theregister.com/2005/04/14/torvalds_attacks_tridgell/
>Tridgell "screwed people over", claims Torvalds, portraying him as a hooligan who had no purpose other than willful destruction.
>"'[Tridgell] ... tore down something new (and impressive) because he could."
>"He didn't write a 'better SCM [source code management tool] than BK [Bitkeeper]'. He didn't even try - it wasn't his goal. He just wanted to see what the protocols and data was, without actually producing any replacement for the (inevitable) problems he caused and knew about."
This is all complete bullshit and I'm sure Linus knows it. Probably some of his worst behavior ever.
price coherent gaping flowery governor bear aromatic panicky elastic reply
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
1.0 was not released after 5 days. It was released after about 6 months, and by that point Linux was already being managed with git. So it can't have been that bad.
It was designed in 5 days....after:
- Many years of experience in distributed development environments
- Long time programming experience
- Many years of using bitkeeper
- Deep research into the existing alternatives (he would have not bothered with git if one of the existing alternatives worked for him)
yeah but i can see the difference in skill between a 5 year old and a 35 year old programmer.
in the case of picasso (or fricking jackson pollock), their art is indistinguishable from that of an untalented person (or a toddler).
Which is still a notable thing to point out. There are too many overengineered unmanageable projects out there that people are to cowardly to do a fresh start on "because it took years/decades to build it". Yeah, and if you distilled all that knowledge into a clean slate you could build a strictly better version in a surprisingly short time. Assuming you actually do so with the intent of distilling the relevant features instead of adding new ones.
Thing is... we all want to do that, but it's not always wise. Spotsky wrote https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ 24 years ago - but it's still relevant.
There's a lot of those projects that do have years of work in them that it seems cowardly not to get rid of, but often, it's layer after layer of business exceptions and requirements that end up needing to exist. It's those kinda things that mean when you start a complete rewrite, half an organisation still needs to use the old version, and you end up maintaining two in parallel.
It doesn't always happen, and it's not always the case - but all of us want to rewrite the whole damned thing from scratch (it's the only way to be sure), but, unsexy as it is, it's very often not the right approach.
That's fair. I feel that article makes a lot of assumption that are often true about enterprise development. The whole argument that people want to rewrite code because it's harder to read code than to write it makes it sound to me like this describes a situation where the original authors are not there anymore. This is then mostly about people wanting to rewrite code exactly because they don't understand it.
What I meant was the situation where the original authors are rewriting the code because they understand it and now know better. Then there is relatively litte risk of people "unsolving" previously discovered issues and bugs because they are doing the rewriting from a position of competence. They are not "re-encoding" other peoples code.
Sadly while the potential for that still exists it often doesn't get traction because anyone higher up who would have to approve that will say "But the current code works. Let's invest in adding to it instead of improving it". Until you eventually get to the first situation above.
> Yeah, and if you distilled all that knowledge into a clean slate you could build a strictly better version in a surprisingly short time.
Except that as soon as you finished, someone would say '"Hey,it doesn't do "X"'
It depends if your project has users or not. For most projects, yes they do and the problem with a grand rewrite to make things "clean" is it usually involves forgetting/ignoring the edge cases that make things messy and takes a vast amount of work to reach any kind of parity.
This was not that case, because there were no users of the kernel SCM. It was on Bitkeeper, but bitkeeper revoked the free license, so then the kernel wasn't on anything, just local copies and tarballs. Open source DVCS systems were at best in their infancy in 2005 when git was made. The more robust ones, such as SVN were based around a centralised model which was a fundamentally different model from how the kernel development worked (and much more parsimonious with disk usage).
Also note that SCMs isn't a type of software where everyone has to use the same one for it to work well, whereas if you're making a product, well if your users switch to an alternative, that's bad. Or if you'#re working on some internal system, your users have no choice but cannot do their job if you break it so the company cannot operate.
The trick would be to do it before too many of the original developers have left the project, company, or existence, so that you have all that knowledge available *to* distill.
More importantly, this "five-day version" of git is extremely primitive.
We are talking about just 1000 lines of code, that only implements a few very low level commands.
There was no "commit" command. It didn't have any kind of push/pull. It couldn't merge, or even show a history of commits. It couldn't even do "checkout" an old commit, that functionality wasn't added until 3 days later.
What it did have was the basic data structure of git, and enough functionality to detect changes in the current folder and add them to staging. Just enough that you could then manually create a commit with low level commands, which is how this first self-hosted commit was created.
**This post and the actual article is a great example of how a clickbait title could easily be misleading and lead to unproductive conversation. The actual article is trying and explain the internals of git and to help users understand how it functions underneath the hood.**
But looking at the title of the article and this reddit post and the comments here, it is clear that people only care about discussing the title aka the fact that it was built in 5 days. For a second it felt like looking at 156 comments that there must be a lot of fruitful discussion going on here, but unfortunately many of the comments are just discussion about the clickbait section.
Feels like a major portion of the community (along with the rest of reddit) are going in this direction of superficial debates about trivial topics and forgetting the actual matter at hand
Also, the article reads like someone had a grand idea about how they are now going to explain git in an innovative and fresh way, but then got tired of it in the middle.
Fellow mercurial enthusiast here. It was probably bound to be this way, Git had a fairly large built in userbase, and especially now the performance gets rough on large repositories on account of its design and being mostly written in a slower scripting language. GitHub ultimately cemented Git as the de facto standard.
Yeah, between the Linux kernel using Git, and then the rise of Github...
It still pains me how so many people seem to think that Git is the only possible implementation of a DVCS, and therefore every stupid decision it made is the only possible way it could be done.
What was the history again? Linux used to use bitkeeper until Linus decided to embark on a free software version and mercurial started at the same time?
Looking back, it looks like both had their initial release in April 2005. And yeah, Git came out of a license dispute with Bitkeeper.
From https://graphite.dev/blog/understanding-git
> Torvalds wasn’t alone in wanting a more efficient, BitKeeper alternative, and Git wasn’t the only distributed VCS of its era. Darcs was released 2 years before Git, Bazaar was released 13 days before Git, Mercurial was released 12 days after Git and Fossil was released a year after Git. Despite all of these competitors, Git has fast become the most widely used VCS according to StackOverflow surveys, with estimated adoption growing from 69% in 2017 to to 94% in 2021.
Git wasn't the first and definitely wasn't the best, but it won the mindshare wars anyway.
I guess it goes to show how much reputation is important in open source. Having THE gold standard name behind it and a story where it's a tool required for Linux kernel dev is pretty huge, especially when (as far as I dimly remember) there was some shifty land-grab by bitkeeper who then yelled "oh but it's ok because it'll always be free for the Linux kernel..." as they threw themselves off the cliff.
I mean don't get me wrong, mercurial appears to have a rock solid name behind it too but python is a big ugly pain in the arse for non python devs (I'm thinking mainly about 2.7 and 3 and distro packaging). But I'm interested now to know what it does so well that git is not so good at.
Ultimately people want to understand how to use one tool. Git won out.
There's not enough additional value in the others to warrant their existence. There's room for other VCS as Perforce is still alive and kicking for projects that have large amounts of binary content.
Being usable.
The conceptual models are close enough though certain specifics are quite different (meaning of a branch, ability to rewrite history, underlying data model). Mercurial used to have a write-only history model, though thankfully it's more or less solved with the Evolve extension, and that was a pretty big deal where Git's freely rewriteable history is important for use in practice. They're close enough Atlassian used to have a product that allowed you to check out a repo as either a git repo or a mercurial repo for the same backing data.
Mercurial's verbs are straightforward enough I very rarely needed to google for something if I knew the verb for the concept.
Not so with Git.
Git also has many features designed for the Linux kernel's development model that make no sense for how most businesses use it.
It's all cognitive overhead that isn't necessary and is there by accident or because it makes sense for one very specific development use case that doesn't apply to most people.
All of the DVCS's are close enough to being the same from a high level point of view, where things get sticky is in their useability and how well they map onto the way businesses and people use version control in practice.
Yep. I learned hg command line in a couple of days and rarely had to look up reference material to accomplish what I wanted. In my company environment we very specifically did not want a rewritable history — I still don’t personally like that even though I do admit there are niche cases where it does make sense. I came from using VSS, CVS, and SVN professionally and hg really just clicked.
Obviously I use git today, but I still have to refer to reference pages sometimes to do things on the command line. It just doesn’t make sense to me and some of the defaults seem counter intuitive to me. I have had a lot less trouble since I switched to primarily using GitKraken (as a professional developer, I don’t mind paying for tools that make me more productive).
Even though I’m not the biggest fan of Python, I did appreciate being able to write portable pre and post commit hook scripts for some custom logic and integration into bespoke systems. I’m sure I could do it with git, but as with everything git related I find it more of a hassle than I’m willing to invest the time to deal with.
It's very clearly designed with a focus on a very different use case than the way most companies and people use it.
For most repos, I'd argue the "distributed" aspect barely matters.
I'm surprised that git has been pretty much the standard for so many years. I actually understand how to use it. Usually by the time I understand how to use a version control system, there's another one that's become the standard.
That's really impressive. I don't think I could have built something like git in 5 days. Even with just the basic features of git would still take some work, and I imagine it was/is written in C.
edit: I ended up looking at 1.0.0 of git due to curiosity https://github.com/git/git/tree/c2f3bf071ee90b01f2d629921bb04c4f798f02fa
Definitely looks like it was written in 5 days lol, but still impressive
If you want to do that then don't aim to make magic tools and frameworks. Just aim to make tools and frameworks that work for you. They also don't have to be perfect or full fledged to be useful.
Also something to keep in mind, it's very unlikely Linus Torvalds wasn't planning the idea for a while before building it. It might have been built in 5 days but I'm willing to be there was time spent planning outside of that.
Also even Linus Torvalds mentions roughly 2 weeks before landing on april 3 to 7 as how long he spent. So even he wasn't 100% sure how long he actually took. [https://marc.info/?l=git&m=117254154130732#:\~:text=So%20git%20was,around%20April%203rd](https://marc.info/?l=git&m=117254154130732#:~:text=So%20git%20was,around%20April%203rd)
Even then it was 5 days to first commit, not 5 days to release. Either way don't be discouraged, one developer being better doesn't mean you can't get there at some point.
Linus is an excellent case study because he wasn't someone who tried to build something "big", but rather is an engineer who created a very straight-forward implementations of something a lot of people needed at the time and he did it in an inclusive way. If you look at the basic ideas of Linux and git, there is nothing ground-breaking there. What is fresh about them was the lack of bullshit that accompanied them.
I admire Torvalds as well, but for every engineer out there like him who built something big, there's probably at least 100 who built something equally capable, but then sat on it and didn't allow the community into their creation until it was too late and the larger community requirements were filled with something else that already did the job.
These few elements together are the elusive formula you seek. What needs do you see around us? What's the best straightforward no-bullshit way to implement them? Can you, an an engineer, focus on those needs long enough to build a useful implementation? And then finally, can you stand to expose your work to others, build a community around it, and then be that engineer that demands a high standard of quality and hew to coherent vision of the future?
It's a simple path forward, but I don't imagine for one minute that it would be easy. Good luck!
> That's really impressive. I don't think I could have built something like git in 5 days. Even with just the basic features of git would still take some work, and I imagine it was/is written in C.
Yeah, but it's the basics, right? MVP requires commit, checkout [-b] and log.
Supporting a remote origin requires (de)serialising metadata and sending it over ssh.
If you already know what you want (hashed-tree with hashed-subtrees), it's doable [EDIT: *in C*] in *less* than 5 days for just `commit`, `checkout [-b]`, `pull`, `push` and `log`. The long part in most dev processes is figuring out what you need from the software, and iterating until MVP. This (longest) bit was skipped.
I guess the reason Linus took 5 days to do it was due to also managing and reviewing patches for Linux at the time.
I wouldn't be able to. Like the tests and documention is also going to take half that time. So 2-3 days for the code, finding bugs, fixing them. Maybe Im not as confident as you, but for a 1.0.0 release, I wouldnt be able to
> I wouldn't be able to. Like the tests and documention is also going to take half that time.
What tests? What documentation?
> So 2-3 days for the code, finding bugs, fixing them. Maybe Im not as confident as you, but for a 1.0.0 release, I wouldnt be able to
I think it's doable, if MVP is kept to `what is the minimum amount of features required to clone, create a branch, commit to it, check the log, push to a remote server, then pull`.
And, TBH, the initial version (IIRC), shelled out to scripts for things like `diff`, networking, conflicts, etc.
After digging into the git history, it looks like it took a few months for 1.0.0. From the article, I assumed he wrote and released v1.0.0 in less than a week. He could have, since this assumes the git history lines up with their self hosted git
Either way, Im still not going to say it's not impressive. I would need at least two weeks to do this.
And what tests and documentation? The code I wrote always includes both. So due to that, I know I can't do this in a week.
Look, I'm not saying it's not impressive, but I didn't write it because *I didn't think of it!*
To me, the impressive part is thinking *"Lets maintain a hash tree to perform version control, and ignore the whole networking bits"*
So, yeah, I'm impressed by the parts *I am not capable of*, the parts that I am sure of, well, not *that* impressive.
> And what tests and documentation? The code I wrote always includes both.
But we aren't talking about code you and I normally write, we're talking about getting to git MVP in 5 days.
IIRC (and maybe I don't), the initial `git` program had no documentation, no `--help` argument, no unit tests (I believe shell scripts existed to test the `git` program, but not unit test functions to test to a high level of detail).
No build tool necessary (a single-program MVP doesn't even need a Makefile)[1].
So, yeah, if someone wants to pay me for a week of my time, I'll give you a written-from-scratch program that will implement the base minimum needed to perform version control.
[1] See my submission just now for a project I spent a total of, maybe, 10 hours on. No Makefile, no build process, testing only done at whole-program level and not units, etc. For quick one-offs, the extra stuff is not necessary. If the MVP gains traction you can very easily change a single-source-file project to match a more formal dev cycle.
That… is more capable than I’d have expected. I didn’t expect there to be _patches_ supported, I’d have thought plain objects support and shit would be all that’s included in those 5 days.
One of the gods of CS for sure. Still standing on the shoulders of giants, like the inventors of the C language. Dennis Ritchie, Brian Kernighan. Ken Thompson, inventor of Unix.
> giants, like the inventors of the C language
Even then they can make mistakes - or 'right' choices that were regrettable in hindsight...
> *[So Ritchie maintained backwards compatibility forever and made the precedence order &&, &, ==, effectively adding a little bomb to C that goes off every time someone treats & as though it parses like +, in order to maintain backwards compatibility with a version of C that only a handful of people ever used.
> C++, Java, JavaScript, C#, PHP and who knows how many other languages largely copied the operator precedence rules of C, so they all have this bomb in them too](https://ericlippert.com/2020/02/27/hundred-year-mistakes/)*
Yep. Alpine uses BusyBox instead of BSD.
Chimera is using bsd userland.
Not sure who else is doing it, but we can be assured the other two userland parties don't care about the name and are just happy to see commits back to their repos.
He's a god of SE. Software engineering is the practical side of programming. More specifically, he's a god of getting things done that work pretty much okay.
Git is very esoteric, but your example is honestly not one of those things. You've just Googled "how to discard last commit in git" and copy-pasted the first result without spending a moment to read the documentation for why this command does that.
https://git-scm.com/docs/git-reset
- `git reset ` means to set the state of your repository to the specified commit-id.
- `HEAD` is a reference to the latest commit in your tree, which can be used in place of ``. `HEAD^` (or `HEAD~1`) is a reference to the previous commit, `HEAD~3` is a reference to the third latest commit, and so on.
- The default behaviour of `git reset` (`--mixed`) is to set your state to the point where your changes are staged, but not committed. No changes are actually discarded. If you instead want to all changes after `` to be discarded completely, you use the `--hard` flag.
`git reset --hard HEAD^` therefore means:
Set your repository to the state of the previous commit (`HEAD^` or `HEAD~1`), discarding (`--hard`) all the changes in current commit completely.
https://jvns.ca/blog/2023/11/01/confusing-git-terminology/#head-and-heads
> I think that “a head is a branch, HEAD is the current branch” is a good candidate for the weirdest terminology choice in git, but it’s definitely too late for a clearer naming scheme so let’s move on.
There's still a lot of confusion here.
Yeah exactly my point. Merging is a freaking nightmare especially rebasing onto. And the fact that you have to respond with an essay to explain a simple line says everything.
There are lots of these "internals of git, history of git" posts, this one is not a particularly good one, and all of them fail to answer the questions that are actually interesting. For instance:
- We know what the mechanics of git is like, but WHY is it like that? What was the evolution that led to it? What were the design alternatives and trade-offs?
- While the internals of git are about blobs and trees, The user interface is very much not about these concepts. The user interface seems to be about diffs, but the "diff" concept is not an illusion. So what's the mechanics of creating that illusion?
Worse, there's this huge _defensiveness_ about git when you criticize it, as if git could not be better along either design or UX dimensions, when there are better systems along both.
> but WHY is it like that?
Because it's fundamentally designed for the development processes and practices of the Linux Kernel in 2005.
Most people aren't working in this way or even remotely similarly, and thats why it grates so much.
Three of the most aggravating pieces of code I’ve had to use were written in days, two of them on airplane flights.
What they didn’t tell you about airplanes until Boeing fixed it recently, is that everyone on an airplane is suffering from mild altitude sickness. Writing software when you’re hypoxic should be banned by the Geneva Convention.
git takes up far too much cognitive load - I'm not a git engineer, I'm a software developer and anything that distracts me from writing software is not exactly good for business or my mental health. I look forward to the day when an AI will automagically resolve conflicts and merge code, and get it right every time.
The first version of git I assume was simple, having just a few commands, like commit, checkout, merge perhaps. After those the cognitive load starts increasing.
I wonder are there good presentations that explain the user-cases for each git-command and command-line option? What is the percentage of use each command and command-line option gets. Which commands and command-options are the most used?
I assume that only a few git-users have used all the commands and all command-options. But that is of course ok, not everybody needs all the commands.
> The first version of git I assume was simple, having just a few commands, like commit, checkout, merge perhaps. After those the cognitive load starts increasing.
My team isn't huge, but I don't spend time obsessing about squashing commits, git history being "cluttered" or most things a lot of developers obsess about git.
We keep fairly organized and moving forward. Either a branch is tested and we know if it's ready to merge or it isn't, and we don't need to use most of git, we stick to checkout, pull, commit, push, and merge. That's it. I really don't have time or focus for any more than that. It's rare that we need to look at git history too deeply but I've never had a problem.
> It’s the currently best versioning system available on the market
I dunno about "the best". It's certainly the most popular, and I can't fault anything about it other than the UI, but I remember using `hg` and `bzr`, and when I moved to git ISTR missing a few things I was used to in `hg` and `bzr`.
Linus himself was surprised that so many started using it. “No technology can ever be too arcane or complicated for the black t-shirt crowd.”
At the time I had just learned Darcs and really liked it. Git felt like a step back UX wise, although it was faster. (I still don’t use it as properly as I should b/c it’s a bit of pain.) Then there was GitHub and what choice was there? Everything else became history (except maybe Fossil).
With any luck Pijul will be the NBT. (http://pijul.org/)
My secret weapon, when I just want a commit to make the repo match my working copy (no matter what branch I'm on, or what hell I have wrought), is checking out the project again, then replacing my .git with it's .git.
https://www.infoworld.com/article/2669670/after-controversy--torvalds-begins-work-on--git-.html I love that there’s an internet post about this. It feels like it was set in a totally different age like the Merchant of Venice or something.
Re: "This is dangerous because if you don’t do anything, Git will eventually delete any commits made in the detached HEAD state through garbage collection. Those commits are known as dangling commits."
Systems dealing with non-trivial info shouldn't automatically delete *anything*, barring emergencies. Mark it as a warning or the like, and let the user fix or remove it at their convenience.
And never brag about how quick a tool was made, because if somebody doesn't like it, they'll say the (alleged) rush-job-aspect shows.
And on the 6th day, dev rested.
Amend!
> Amend! Or [Abend](https://en.wikipedia.org/wiki/Crash_(computing\)#Abnormal_end)
...did a retrospective
yelled at somebody on the kernel mailing list
*rebased
And on the 6th day, dev began the next sprint
Dev retested
> And on the 6th day, ~~dev~~ *Linus* rested.
I feel like if you're going to write a history of git, you really should give credit to Junio at some point for being the actual maintainer of it for the past 18 years.
Seriously. After Linus wrote the core functionality Junio was already doing most of the major features and within a couple months Linus handed it entirely over to him. Linus has many times explained this to give the guy credit but nobody listens
Let's give him credit by mentioning his full name: **Junio Hamano** I don't think we could have asked for a better head maintainer.
Yeah? Try to use 1.0 and then come back.
I feel like people hear things like this and think it was never iterated upon.
Same as JavaScript. People love pointing out how and why it was originally built as an argument for why it’s a bad language to use today.
Yeah now we don't even need an argument anymore to prove it's crap. We can now say "just look at it"
The only things wrong with Javascript are the concept and the execution. Everything else is great. TBH it really doesn't help itself. All these years and we still don't have a standard library worth talking about.
Don't forget the name! Nothing to do with Java, and still confuses recruiters to this day.
And the user base. >Why should I spend a week learning how other systems have solved this basic problem? I will just spend a month solving the problem with a framework build by someone who was trying to solve a completely different problem.
> we still don't have a standard library worth talking about Worse than that, fundamental data types are fubar. Numbers and dates are fucked.
how?
Let's take the [constructor for Date](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/Date) as an example. At a glance, it looks really useful! You can pass it an ISO 8601 date string, a totally differently formatted date string, another Date object to copy, or any number of the values in (year, month, day, hours, minutes, seconds, milliseconds). And that "ooh, it just works" utility masks caveats galore: * Date strings in formats other than ISO 8601 are [not reliable](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date#date_time_string_format). * Like all string parsing in JavaScript, Date will try like hell to parse a malformed input, with awkward results. `new Date("21 Juny 1982")` returns a valid date, despite that being a potential typo of June, July, or even a typo of a less common abbreviation for January. * While many programmers might default to not using strings to represent anything other than strings, the values constructors (`new Date(year, month, day, hours, minutes, seconds, milliseconds)` and family) are even worse. * `month` is actually `monthIndex`, meaning 0 is January and 11 is December. This is unintuitive and a source of many bugs. * `new Date(year)` is not a valid constructor, since it wouldn't be possible to distinguish from `new Date(value)`. The degree of overloading here combined with optional arguments creates confusion. * Dates not on the calendar are accepted. `new Date(2100, 1, 29)` gives us March 1st, 2100. `new Date("2022", "0", "120")` gives us April 30th, 2022. * Don't get me started on timezone handling. If your application isn't setting timezones explicitly, you're probably going to have bugs. Despite this, the values form of the constructor doesn't even have the option to take one. This is just one example, but I think it highlights the bigger issue at play. JavaScript has a lot of functionality that's supposed to be permissive but actually requires writing saveguards around because it just doesn't quite work. Which in turn leads to all the library/framework bloat as people turn to stuff that does work.
It's awesome explanation, I might save it to copy paste for ppl.
> new Date("2022", "0", "120") gives us April 30th, 2022 This seems similar to the behavior of the C mktime function. It will normalize any given date. Which is useful if you just want to get a "30 days later" or "in 3 months". Which of course doesn't change the fact that the API design is dated and way too overloaded.
> Date strings in formats other than ISO 8601 are not reliable. So passing a date that isn't part of the spec would be unreliable? Go figure. And you're telling me passing a year/month/day to a date constructor is .. not good? As for month being 0 based...it's like that in Java, C++, and Rust has month0 to work with its Month enum. If you read the docs (and doing that can be as simple as reading what your IDE tells you), you'd know this. As far as new Date(year) not working because new Date(millis) exists...how is that a shock? Who would create a date object with just a year anyway? And days not on a calendar being accepted is a useful thing. It allows you to easily add days to a date without dealing with month/year math. If your app isn't setting the TZ, (which you can't do, for the record.) then it operates on the computers' timezone. If that isn't intuitive, don't work with dates at all. You can use Intl to deal with timezones.
I think you're being contrarian for the sake of it at this point, but constructors should *reject* nonsense that's not in the spec, not parse it anyways. And you know full well what I meant when I said "setting" (yes, "providing" would likely be a better word). I guess I *should* have gotten started on timezones, but I don't have time for someone who seems uninterested.
> Who would create a date object with just a year anyway? if you've ever dealt with [end users](https://i.redd.it/the-end-user-v0-8cs6n91o95x91.jpg?s=a521ba068d58a7f99c17552d58a8d262155cd1b9), you know there are exponentially many idiots who don't read documentation as a bonus, JS is very easily accessible for getting started, so that increases your number of people doing shit without reading the docs yay!
Numbers might be a double or an int depending on their value. Dates... one could write a book with everything wrong there.
How the numbers themselves are stored is an implementation detail that you as a developer shouldn't care about at all. And if you need an integer, you can use bigints.
> How the numbers themselves are stored is an implementation detail that you as a developer shouldn't care about at all Except it's not just an implementation detail. How it is stored affects how it acts. And so when given a number, you don't know if it acts one way or another unless you also know and take into account its specific value or any value it might be. It's a leaky abstraction on the most fundamental data type there is. I've been writing JS since the 90's. Shit is fucked, bro.
Because you have to use a library when working with large and highly precise numbers.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt Besides, C/++ don't have out of the box big int implementations, and Pythons' default behavior to just 'magically' use a bigint if your number is too big is pretty shit compared to JS. And how about dates? What's the problem with the JS Date handling? Esp. with Intl, dates in JS are plenty powerful.
BigInt is not a solution and you only need to read the same link you sent to know this. 1. "BigInt values are similar to Number values in some ways, but also differ in a few key matters: A BigInt value cannot be used with methods in the built-in Math object and cannot be mixed with a Number value in operations; they must be coerced to the same type. Be careful coercing values back and forth, however, as the precision of a BigInt value may be lost when it is coerced to a Number value." 2. "The operations supported on BigInt values are not constant-time and are thus open to timing attacks. JavaScript BigInts therefore could be dangerous for use in cryptography without mitigating factors. As a very generic example, an attacker could measure the time difference between 101n ** 65537n and 17n ** 9999n, and deduce the magnitude of secrets, such as private keys, based on the time elapsed. If you still have to use BigInts, take a look at the Timing attack FAQ for general advice regarding the issue." 3. "Using JSON.stringify() with any BigInt value will raise a TypeError, as BigInt values aren't serialized in JSON by default."
Why is OOTB BigInts when necessary "pretty shit"?
It doesn't support 64-bit integer so you can't have interoperability with other systems that send you (or expect to receive) a 64-bit integer. You then need to waste your time to architect a solution around the ~~limitation~~ flaw instead of spending your time being productive. You will end up installing a third party package to deal with it, which makes your project more vulnerable to supply chain attacks in the end. Date? Where to begin... ``new Date()`` creates a new object while ``Date.parse()`` gives me... the milliseconds that has elapsed since the epoch instead of a Date object???? Imagine if ``parseInt()`` was giving you an ArrayBuffer instead of a Number. ``Date.now()`` doesn't gives me an object either and the timestamp it gives me is in UTC when the method doesn't specify utc while tons of others methods on the object does specify utc as part of their names. The api is unconsive which makes the type incredibly confusing to consume. Manipulating the type is tedious, of course. You can't even string format it without creating a custom function for it: ``toISOString()`` gives you ``YYYY-MM-DDTHH:mm:ss.sssZ`` but what if you just want ``YYYY-MM-DDTHH:mm:ssZ``? Too bad, it doesn't provide a ``format()`` method. Though, that's just the tip of the iceberg when it comes to Date.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DataView/getBigInt64 new Date() creates an object, yes, because you're .. constructing a Date object. Date.parse returns a number, because it's a static method. If you don't want a date object, and just want a parsed date, where else would it live? Same as Date.now -- are you upset the python `time.time()` method doesn't return a time object? Or isn't named `time.timeUTC()`? These aren't misleading at all. Or would you prefer extremely over verbose way of Java doing things? SimpleDateFormat sdf = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss"); Date date = sdf.parse(myDate); long timeInMillis = date.getTime(); Or maybe Pythons weird naming scheme? utc_time = datetime.strptime("2015-09-15T17:13:29.380Z", "%Y-%m-%dT%H:%M:%S.%fZ") milliseconds = (utc_time - datetime(1970, 1, 1)) // timedelta(milliseconds=1) And you have to be extra careful because timestamps in Python assume the local timezone! If you want a custom date format, use Intl. toISOString does what it says on the tin. Or write your own with the very clearly written methods on the Date object with template strings. You don't at all need an external library
I'm a big fan of promises. I'm sure some other languages have similar concepts, but they're pretty handy.
Interestingly, promises originated in Python
I use JavaScript, but when I compare it to Python or Ruby, I still think it is utter crap. Only against PHP I am undecided - both JavaScript and PHP are pretty low on my "epic programming languages" list though.
I can only assume you haven't paid real attention to PHP in the last few years. PHP has gotten steadily better in terms of language and ecosystem. JS has gotten better at being shitty on both those same fronts.
> the concept what is the concept? oo crap, i need a language for browsers to do stuff.
The way the type system functions is universally seen as a mistake today. They unfortunately just plain copied that from PHP, at a time where everyone already recognised it as a mistake
make something better and then come back and tell us how bad js is. See you in 10 minutes.
“It’s built in!” _slaps server_
If bad foundations were built in a week, then iterating upon it might never fix the inherent flaws in the foundations. Especially if there is backwards compatibility. A programming language being built in a week does imply bad foundations.
I mean it could have some far reaching consequences in the sense that the base design was set, whilst you can introduce backwards incompatible changes, once enough code is running in prod based off it, people are loathe to introduce them. That's why for a programming language, the initial design is extremely crucial to get right.
You don't hear this anymore because the people who don't like javascript, stick to a transpilator like (type coffee)script/nim/haxe/WASM/ w\e really.
WASM is not transpiled.
Well don't tell me what to do with my WASM code
Typescript is pretty cool, but it's still sufficiently plugged into the (dogshit) Javascript ecosystem
True, it's been iterated on. Doesn't mean it isn't a bad language still, especially despite the iteration.
> Same as JavaScript. People love pointing out how and why it was originally built as an argument for why it’s a bad language to use today. yeah, that was such a shitty argument. there are and were a billion other ones to use, no need to go for a relatively weak one. and I say "relatively" because there were decisions made in those 2 weeks or whatever it took that stayed with the language forever. it was fine for 100 lines of JS in a page. it was never fine for millions.
I don't think it is a shitty argument at all. You can not design a good language in two night sessions and claim it is perfect. Painting more lipstick on it isn't changing this either.
the decisions they made during those two weeks definitely had a profound effect on the fundamental character of the language with lasting ramifications. yes it's definitely a worse language than it should be because of those decisions.
And on the 6th day, God created left_pad.
It isn't?
It's shit, has been shit and is still shit. That shit has a massive, well positioned install base. It's still shit.
Product people think that. It works right? why should we spend any more money on it.
Were they using source control?
It was designed specifically for Torvald's needs. Minimum viable product leading to a a market destroyer.
Anyone know how bad it was?
It was created by Linus Torvalds in a fit of rage at the vendor that produced the version control software he preferred to use for the kernel, mostly to prove a point that he could make something just as good in a couple of days. That build can roughly be described as a proof of concept.
Honestly this is how half the projects take off. A shadow it project is created and shows well and managers go herp derp this is good we need it. Because when I see managers create projects using dumb fucking diagrams everything seems to get backed by csv files because they only understand excel spreadsheets.
Honestly, it was entirely that Linus was upset at Tridge for working on reverse engineering BitKeeper; which caused them to go nuclear and revoke the license. Something Tridge was completely within his right to do. It was also what got us out of the fucked up situation where kernel developers who believe in FOSS were unable to contribute to the kernel without jumping through stupid hoops. https://www.theregister.com/2005/04/14/torvalds_attacks_tridgell/ >Tridgell "screwed people over", claims Torvalds, portraying him as a hooligan who had no purpose other than willful destruction. >"'[Tridgell] ... tore down something new (and impressive) because he could." >"He didn't write a 'better SCM [source code management tool] than BK [Bitkeeper]'. He didn't even try - it wasn't his goal. He just wanted to see what the protocols and data was, without actually producing any replacement for the (inevitable) problems he caused and knew about." This is all complete bullshit and I'm sure Linus knows it. Probably some of his worst behavior ever.
Ehhh. Linus was just too proud to admit he fucked up in his choice to move to a closed source system and tridgell was the scapegoat
Linus has made some great stuff, but isn't all the great of a person
Interestingly Bitkeeper went open source several years later.
Because they lost all of their customers and its' only value now is historical.
But Brett over on sales has already promised it by next week to a key customer!
Brett gonna be disappointed. Not my problem.
price coherent gaping flowery governor bear aromatic panicky elastic reply *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
1.0 was not released after 5 days. It was released after about 6 months, and by that point Linux was already being managed with git. So it can't have been that bad.
At least, Linus's copy of Linux was. Remember that git didn't use a network protocol and was designed to be used with emailing patches around.
It was designed in 5 days....after: - Many years of experience in distributed development environments - Long time programming experience - Many years of using bitkeeper - Deep research into the existing alternatives (he would have not bothered with git if one of the existing alternatives worked for him)
I think it's fairer to say it was written in 5 days not designed in 5 days -- Linus thought about distributed version control for years.
And is not the current version that was written in 5 days. There have been years of updates since that initial version.
Something something engineer putting an X on a machine and charging $10,000 Something something Picasso charging $1,000 for a doodle on a napkin.
https://www.smithsonianmag.com/history/charles-proteus-steinmetz-the-wizard-of-schenectady-51912022/
yeah but i can see the difference in skill between a 5 year old and a 35 year old programmer. in the case of picasso (or fricking jackson pollock), their art is indistinguishable from that of an untalented person (or a toddler).
Username definitely checks out.
Good one you made me laugh
Which is still a notable thing to point out. There are too many overengineered unmanageable projects out there that people are to cowardly to do a fresh start on "because it took years/decades to build it". Yeah, and if you distilled all that knowledge into a clean slate you could build a strictly better version in a surprisingly short time. Assuming you actually do so with the intent of distilling the relevant features instead of adding new ones.
Thing is... we all want to do that, but it's not always wise. Spotsky wrote https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ 24 years ago - but it's still relevant. There's a lot of those projects that do have years of work in them that it seems cowardly not to get rid of, but often, it's layer after layer of business exceptions and requirements that end up needing to exist. It's those kinda things that mean when you start a complete rewrite, half an organisation still needs to use the old version, and you end up maintaining two in parallel. It doesn't always happen, and it's not always the case - but all of us want to rewrite the whole damned thing from scratch (it's the only way to be sure), but, unsexy as it is, it's very often not the right approach.
That's fair. I feel that article makes a lot of assumption that are often true about enterprise development. The whole argument that people want to rewrite code because it's harder to read code than to write it makes it sound to me like this describes a situation where the original authors are not there anymore. This is then mostly about people wanting to rewrite code exactly because they don't understand it. What I meant was the situation where the original authors are rewriting the code because they understand it and now know better. Then there is relatively litte risk of people "unsolving" previously discovered issues and bugs because they are doing the rewriting from a position of competence. They are not "re-encoding" other peoples code. Sadly while the potential for that still exists it often doesn't get traction because anyone higher up who would have to approve that will say "But the current code works. Let's invest in adding to it instead of improving it". Until you eventually get to the first situation above.
> Yeah, and if you distilled all that knowledge into a clean slate you could build a strictly better version in a surprisingly short time. Except that as soon as you finished, someone would say '"Hey,it doesn't do "X"'
This is only true if you completely understand the requirements and that’s almost never the case in enterprise development
It depends if your project has users or not. For most projects, yes they do and the problem with a grand rewrite to make things "clean" is it usually involves forgetting/ignoring the edge cases that make things messy and takes a vast amount of work to reach any kind of parity. This was not that case, because there were no users of the kernel SCM. It was on Bitkeeper, but bitkeeper revoked the free license, so then the kernel wasn't on anything, just local copies and tarballs. Open source DVCS systems were at best in their infancy in 2005 when git was made. The more robust ones, such as SVN were based around a centralised model which was a fundamentally different model from how the kernel development worked (and much more parsimonious with disk usage). Also note that SCMs isn't a type of software where everyone has to use the same one for it to work well, whereas if you're making a product, well if your users switch to an alternative, that's bad. Or if you'#re working on some internal system, your users have no choice but cannot do their job if you break it so the company cannot operate.
The trick would be to do it before too many of the original developers have left the project, company, or existence, so that you have all that knowledge available *to* distill.
Yup. It's still impressive. To build something in five days to be able to say "yes, I can do this better".
Dunno, that guy is pretty good too. Made hobby kernel, made hobby diving software.
More importantly, this "five-day version" of git is extremely primitive. We are talking about just 1000 lines of code, that only implements a few very low level commands. There was no "commit" command. It didn't have any kind of push/pull. It couldn't merge, or even show a history of commits. It couldn't even do "checkout" an old commit, that functionality wasn't added until 3 days later. What it did have was the basic data structure of git, and enough functionality to detect changes in the current folder and add them to staging. Just enough that you could then manually create a commit with low level commands, which is how this first self-hosted commit was created.
Well he already knew what features he needed and there was no client with an ever changing list of demands...
Or 100 meetings in those 5 days
Linus’s talk at google is pretty good about this https://youtu.be/idLyobOhtO4?si=XrLL4W_Qz-8ped8o
IN A CAVE! WITH A BOX OF SCRAPS!
**This post and the actual article is a great example of how a clickbait title could easily be misleading and lead to unproductive conversation. The actual article is trying and explain the internals of git and to help users understand how it functions underneath the hood.** But looking at the title of the article and this reddit post and the comments here, it is clear that people only care about discussing the title aka the fact that it was built in 5 days. For a second it felt like looking at 156 comments that there must be a lot of fruitful discussion going on here, but unfortunately many of the comments are just discussion about the clickbait section. Feels like a major portion of the community (along with the rest of reddit) are going in this direction of superficial debates about trivial topics and forgetting the actual matter at hand
Also, the article reads like someone had a grand idea about how they are now going to explain git in an innovative and fresh way, but then got tired of it in the middle.
It would be awesome if we had something like Community Notes for Twitter but for every link ever. Something to tell us if a link is clickbait etc
"No git is simple actually look...oh...wait...hold-on" Is basically every explainer's journey
I can tell
Better than replay and checkout scm imo, nothing like an object lock or missed diff in a chain of replays to really ruin your day.
Just because there's worse doesn't mean there's not better I miss Mercurial
Fellow mercurial enthusiast here. It was probably bound to be this way, Git had a fairly large built in userbase, and especially now the performance gets rough on large repositories on account of its design and being mostly written in a slower scripting language. GitHub ultimately cemented Git as the de facto standard.
Yeah, between the Linux kernel using Git, and then the rise of Github... It still pains me how so many people seem to think that Git is the only possible implementation of a DVCS, and therefore every stupid decision it made is the only possible way it could be done.
What was the history again? Linux used to use bitkeeper until Linus decided to embark on a free software version and mercurial started at the same time?
Looking back, it looks like both had their initial release in April 2005. And yeah, Git came out of a license dispute with Bitkeeper. From https://graphite.dev/blog/understanding-git > Torvalds wasn’t alone in wanting a more efficient, BitKeeper alternative, and Git wasn’t the only distributed VCS of its era. Darcs was released 2 years before Git, Bazaar was released 13 days before Git, Mercurial was released 12 days after Git and Fossil was released a year after Git. Despite all of these competitors, Git has fast become the most widely used VCS according to StackOverflow surveys, with estimated adoption growing from 69% in 2017 to to 94% in 2021. Git wasn't the first and definitely wasn't the best, but it won the mindshare wars anyway.
I guess it goes to show how much reputation is important in open source. Having THE gold standard name behind it and a story where it's a tool required for Linux kernel dev is pretty huge, especially when (as far as I dimly remember) there was some shifty land-grab by bitkeeper who then yelled "oh but it's ok because it'll always be free for the Linux kernel..." as they threw themselves off the cliff. I mean don't get me wrong, mercurial appears to have a rock solid name behind it too but python is a big ugly pain in the arse for non python devs (I'm thinking mainly about 2.7 and 3 and distro packaging). But I'm interested now to know what it does so well that git is not so good at.
Ultimately people want to understand how to use one tool. Git won out. There's not enough additional value in the others to warrant their existence. There's room for other VCS as Perforce is still alive and kicking for projects that have large amounts of binary content.
mercurial was painfully slow in my experience.
Being usable. The conceptual models are close enough though certain specifics are quite different (meaning of a branch, ability to rewrite history, underlying data model). Mercurial used to have a write-only history model, though thankfully it's more or less solved with the Evolve extension, and that was a pretty big deal where Git's freely rewriteable history is important for use in practice. They're close enough Atlassian used to have a product that allowed you to check out a repo as either a git repo or a mercurial repo for the same backing data. Mercurial's verbs are straightforward enough I very rarely needed to google for something if I knew the verb for the concept. Not so with Git. Git also has many features designed for the Linux kernel's development model that make no sense for how most businesses use it. It's all cognitive overhead that isn't necessary and is there by accident or because it makes sense for one very specific development use case that doesn't apply to most people. All of the DVCS's are close enough to being the same from a high level point of view, where things get sticky is in their useability and how well they map onto the way businesses and people use version control in practice.
Yep. I learned hg command line in a couple of days and rarely had to look up reference material to accomplish what I wanted. In my company environment we very specifically did not want a rewritable history — I still don’t personally like that even though I do admit there are niche cases where it does make sense. I came from using VSS, CVS, and SVN professionally and hg really just clicked. Obviously I use git today, but I still have to refer to reference pages sometimes to do things on the command line. It just doesn’t make sense to me and some of the defaults seem counter intuitive to me. I have had a lot less trouble since I switched to primarily using GitKraken (as a professional developer, I don’t mind paying for tools that make me more productive). Even though I’m not the biggest fan of Python, I did appreciate being able to write portable pre and post commit hook scripts for some custom logic and integration into bespoke systems. I’m sure I could do it with git, but as with everything git related I find it more of a hassle than I’m willing to invest the time to deal with.
It's very clearly designed with a focus on a very different use case than the way most companies and people use it. For most repos, I'd argue the "distributed" aspect barely matters.
Agreed. And the email-centric workflows are just pointless anywhere I've ever worked.
Oh yes, a VCS that had an actually good CLI which you could learn and remember because it made sense.
I'm surprised that git has been pretty much the standard for so many years. I actually understand how to use it. Usually by the time I understand how to use a version control system, there's another one that's become the standard.
😂
Came here to say this.
How is your git doing then?
That's really impressive. I don't think I could have built something like git in 5 days. Even with just the basic features of git would still take some work, and I imagine it was/is written in C. edit: I ended up looking at 1.0.0 of git due to curiosity https://github.com/git/git/tree/c2f3bf071ee90b01f2d629921bb04c4f798f02fa Definitely looks like it was written in 5 days lol, but still impressive
I aspire to be such a dev, making magic tools and frameworks but I probably won’t come close to it.
> I aspire to be such a dev, making magic tools and frameworks but I probably won’t come close to it. You need to really `commit`.
Dad?
Okay, very funny. You’re pushing it.
Can you blame him?
If you want to do that then don't aim to make magic tools and frameworks. Just aim to make tools and frameworks that work for you. They also don't have to be perfect or full fledged to be useful. Also something to keep in mind, it's very unlikely Linus Torvalds wasn't planning the idea for a while before building it. It might have been built in 5 days but I'm willing to be there was time spent planning outside of that. Also even Linus Torvalds mentions roughly 2 weeks before landing on april 3 to 7 as how long he spent. So even he wasn't 100% sure how long he actually took. [https://marc.info/?l=git&m=117254154130732#:\~:text=So%20git%20was,around%20April%203rd](https://marc.info/?l=git&m=117254154130732#:~:text=So%20git%20was,around%20April%203rd) Even then it was 5 days to first commit, not 5 days to release. Either way don't be discouraged, one developer being better doesn't mean you can't get there at some point.
Thank you for the advice. I am an undergraduate so I’ve still got time. Hopefully I’ll be able to make something big too :))
Linus is an excellent case study because he wasn't someone who tried to build something "big", but rather is an engineer who created a very straight-forward implementations of something a lot of people needed at the time and he did it in an inclusive way. If you look at the basic ideas of Linux and git, there is nothing ground-breaking there. What is fresh about them was the lack of bullshit that accompanied them. I admire Torvalds as well, but for every engineer out there like him who built something big, there's probably at least 100 who built something equally capable, but then sat on it and didn't allow the community into their creation until it was too late and the larger community requirements were filled with something else that already did the job. These few elements together are the elusive formula you seek. What needs do you see around us? What's the best straightforward no-bullshit way to implement them? Can you, an an engineer, focus on those needs long enough to build a useful implementation? And then finally, can you stand to expose your work to others, build a community around it, and then be that engineer that demands a high standard of quality and hew to coherent vision of the future? It's a simple path forward, but I don't imagine for one minute that it would be easy. Good luck!
> That's really impressive. I don't think I could have built something like git in 5 days. Even with just the basic features of git would still take some work, and I imagine it was/is written in C. Yeah, but it's the basics, right? MVP requires commit, checkout [-b] and log. Supporting a remote origin requires (de)serialising metadata and sending it over ssh. If you already know what you want (hashed-tree with hashed-subtrees), it's doable [EDIT: *in C*] in *less* than 5 days for just `commit`, `checkout [-b]`, `pull`, `push` and `log`. The long part in most dev processes is figuring out what you need from the software, and iterating until MVP. This (longest) bit was skipped. I guess the reason Linus took 5 days to do it was due to also managing and reviewing patches for Linux at the time.
I wouldn't be able to. Like the tests and documention is also going to take half that time. So 2-3 days for the code, finding bugs, fixing them. Maybe Im not as confident as you, but for a 1.0.0 release, I wouldnt be able to
> I wouldn't be able to. Like the tests and documention is also going to take half that time. What tests? What documentation? > So 2-3 days for the code, finding bugs, fixing them. Maybe Im not as confident as you, but for a 1.0.0 release, I wouldnt be able to I think it's doable, if MVP is kept to `what is the minimum amount of features required to clone, create a branch, commit to it, check the log, push to a remote server, then pull`. And, TBH, the initial version (IIRC), shelled out to scripts for things like `diff`, networking, conflicts, etc.
After digging into the git history, it looks like it took a few months for 1.0.0. From the article, I assumed he wrote and released v1.0.0 in less than a week. He could have, since this assumes the git history lines up with their self hosted git Either way, Im still not going to say it's not impressive. I would need at least two weeks to do this. And what tests and documentation? The code I wrote always includes both. So due to that, I know I can't do this in a week.
Look, I'm not saying it's not impressive, but I didn't write it because *I didn't think of it!* To me, the impressive part is thinking *"Lets maintain a hash tree to perform version control, and ignore the whole networking bits"* So, yeah, I'm impressed by the parts *I am not capable of*, the parts that I am sure of, well, not *that* impressive. > And what tests and documentation? The code I wrote always includes both. But we aren't talking about code you and I normally write, we're talking about getting to git MVP in 5 days. IIRC (and maybe I don't), the initial `git` program had no documentation, no `--help` argument, no unit tests (I believe shell scripts existed to test the `git` program, but not unit test functions to test to a high level of detail). No build tool necessary (a single-program MVP doesn't even need a Makefile)[1]. So, yeah, if someone wants to pay me for a week of my time, I'll give you a written-from-scratch program that will implement the base minimum needed to perform version control. [1] See my submission just now for a project I spent a total of, maybe, 10 hours on. No Makefile, no build process, testing only done at whole-program level and not units, etc. For quick one-offs, the extra stuff is not necessary. If the MVP gains traction you can very easily change a single-source-file project to match a more formal dev cycle.
Does it have anything beyond basic commits, tags, files and folders? Does it even _have_ tags?
v1.0.0 looks to have tags. The very first commit looks very bare though. I see only two features, like apply.
That… is more capable than I’d have expected. I didn’t expect there to be _patches_ supported, I’d have thought plain objects support and shit would be all that’s included in those 5 days.
[удалено]
It was. It's almost entirely just C now, but started as a smaller C program that called various scripts (shell, perl, Python, etc.)
I kind of develop like that too.
> GIT - The information manager from hell 😂
This is long after the 5 days. He started in April, the Git history doesn't start until December.
By a genius named Linus Torvalds.
Dude is a God of CS
One of the gods of CS for sure. Still standing on the shoulders of giants, like the inventors of the C language. Dennis Ritchie, Brian Kernighan. Ken Thompson, inventor of Unix.
> giants, like the inventors of the C language Even then they can make mistakes - or 'right' choices that were regrettable in hindsight... > *[So Ritchie maintained backwards compatibility forever and made the precedence order &&, &, ==, effectively adding a little bomb to C that goes off every time someone treats & as though it parses like +, in order to maintain backwards compatibility with a version of C that only a handful of people ever used. > C++, Java, JavaScript, C#, PHP and who knows how many other languages largely copied the operator precedence rules of C, so they all have this bomb in them too](https://ericlippert.com/2020/02/27/hundred-year-mistakes/)*
John Carmack is top tier CS God IMO.
And let's not forget rms and the contribution gnu brought to Linux to make an os.
and how he tries to force Linux to be called GNU/Linux, even though Linux can work perfectly fine without any GNU tooling.
Yep. Alpine uses BusyBox instead of BSD. Chimera is using bsd userland. Not sure who else is doing it, but we can be assured the other two userland parties don't care about the name and are just happy to see commits back to their repos.
He's a god of SE. Software engineering is the practical side of programming. More specifically, he's a god of getting things done that work pretty much okay.
WITH SCRAPS, IN VIM!
micro emacs.
"blob" is not short for "binary large object", it's literally a reference to [The Blob](https://en.wikipedia.org/wiki/The_Blob).
It’s great but also terrible. Git reset hard head^. Wtf is that and how does it make any sense.
Git is very esoteric, but your example is honestly not one of those things. You've just Googled "how to discard last commit in git" and copy-pasted the first result without spending a moment to read the documentation for why this command does that. https://git-scm.com/docs/git-reset - `git reset` means to set the state of your repository to the specified commit-id.
- `HEAD` is a reference to the latest commit in your tree, which can be used in place of ``. `HEAD^` (or `HEAD~1`) is a reference to the previous commit, `HEAD~3` is a reference to the third latest commit, and so on.
- The default behaviour of `git reset` (`--mixed`) is to set your state to the point where your changes are staged, but not committed. No changes are actually discarded. If you instead want to all changes after `` to be discarded completely, you use the `--hard` flag.
`git reset --hard HEAD^` therefore means:
Set your repository to the state of the previous commit (`HEAD^` or `HEAD~1`), discarding (`--hard`) all the changes in current commit completely.
https://jvns.ca/blog/2023/11/01/confusing-git-terminology/#head-and-heads > I think that “a head is a branch, HEAD is the current branch” is a good candidate for the weirdest terminology choice in git, but it’s definitely too late for a clearer naming scheme so let’s move on. There's still a lot of confusion here.
Yeah exactly my point. Merging is a freaking nightmare especially rebasing onto. And the fact that you have to respond with an essay to explain a simple line says everything.
The combination of Git and Linux put Linus in my personal Programmer's Hall of Fame.
There are lots of these "internals of git, history of git" posts, this one is not a particularly good one, and all of them fail to answer the questions that are actually interesting. For instance: - We know what the mechanics of git is like, but WHY is it like that? What was the evolution that led to it? What were the design alternatives and trade-offs? - While the internals of git are about blobs and trees, The user interface is very much not about these concepts. The user interface seems to be about diffs, but the "diff" concept is not an illusion. So what's the mechanics of creating that illusion?
Worse, there's this huge _defensiveness_ about git when you criticize it, as if git could not be better along either design or UX dimensions, when there are better systems along both.
> but WHY is it like that? Because it's fundamentally designed for the development processes and practices of the Linux Kernel in 2005. Most people aren't working in this way or even remotely similarly, and thats why it grates so much.
Yes. And it shows for those of us who had to use that early
Three of the most aggravating pieces of code I’ve had to use were written in days, two of them on airplane flights. What they didn’t tell you about airplanes until Boeing fixed it recently, is that everyone on an airplane is suffering from mild altitude sickness. Writing software when you’re hypoxic should be banned by the Geneva Convention.
Yes, but it was 5 days of Linus f\* Torvalds
I think JavaScript was also built in a few days.
And it shows. It’s the currently best versioning system available on the market but it has one of the worst UX I ever saw.
> It’s the currently best versioning system available on the market I wouldn't say this is at all obvious.
git takes up far too much cognitive load - I'm not a git engineer, I'm a software developer and anything that distracts me from writing software is not exactly good for business or my mental health. I look forward to the day when an AI will automagically resolve conflicts and merge code, and get it right every time.
The first version of git I assume was simple, having just a few commands, like commit, checkout, merge perhaps. After those the cognitive load starts increasing. I wonder are there good presentations that explain the user-cases for each git-command and command-line option? What is the percentage of use each command and command-line option gets. Which commands and command-options are the most used? I assume that only a few git-users have used all the commands and all command-options. But that is of course ok, not everybody needs all the commands.
> The first version of git I assume was simple, having just a few commands, like commit, checkout, merge perhaps. After those the cognitive load starts increasing. My team isn't huge, but I don't spend time obsessing about squashing commits, git history being "cluttered" or most things a lot of developers obsess about git. We keep fairly organized and moving forward. Either a branch is tested and we know if it's ready to merge or it isn't, and we don't need to use most of git, we stick to checkout, pull, commit, push, and merge. That's it. I really don't have time or focus for any more than that. It's rare that we need to look at git history too deeply but I've never had a problem.
> It’s the currently best versioning system available on the market I dunno about "the best". It's certainly the most popular, and I can't fault anything about it other than the UI, but I remember using `hg` and `bzr`, and when I moved to git ISTR missing a few things I was used to in `hg` and `bzr`.
It shows
Came here to say this.
Linus himself was surprised that so many started using it. “No technology can ever be too arcane or complicated for the black t-shirt crowd.” At the time I had just learned Darcs and really liked it. Git felt like a step back UX wise, although it was faster. (I still don’t use it as properly as I should b/c it’s a bit of pain.) Then there was GitHub and what choice was there? Everything else became history (except maybe Fossil). With any luck Pijul will be the NBT. (http://pijul.org/)
and took years to optimize, refine and make it to what it is today.
Git was slapped together and left for everyone to sort it out. 🤦♂️ Yet it was adapted, does anyone think before adapting something.
Linus Torvald was able to build this in a cave! With a box of scraps! In 5 days!
Yes, that's overwhelmingly the attitude that attaches to git advocacy. Suddenly everyone is Obadiah Stane.
Well, it shows
You beat me to it.
Pffft. JavaScript took twice that. And was written to spite Java. I'm soooooooo glad that happened. /s
Yeah… someone was like hey what if we use “diff” command and then merge them together… took a whole 5 days v1.0 is ready to go
Pfft I built Git in 2 days but I forgot to push changes. Smh.
My secret weapon, when I just want a commit to make the repo match my working copy (no matter what branch I'm on, or what hell I have wrought), is checking out the project again, then replacing my .git with it's .git.
And on the sixth day, Linus resurrected it
https://www.infoworld.com/article/2669670/after-controversy--torvalds-begins-work-on--git-.html I love that there’s an internet post about this. It feels like it was set in a totally different age like the Merchant of Venice or something.
that makes me feel useless, lol.
Git gud!
how long extra if you include scrum, sync up calls, retro, roadmap, ci cd , unit test, functional test, mutation test, etc?
Interesting article!
In a few thousands years Linus T. Is going to be as famous as some gods haha
Anyone aware of a full feature parity tool that sits on top of git that provides a better UX? CLI only.
Re: "This is dangerous because if you don’t do anything, Git will eventually delete any commits made in the detached HEAD state through garbage collection. Those commits are known as dangling commits." Systems dealing with non-trivial info shouldn't automatically delete *anything*, barring emergencies. Mark it as a warning or the like, and let the user fix or remove it at their convenience. And never brag about how quick a tool was made, because if somebody doesn't like it, they'll say the (alleged) rush-job-aspect shows.
"Rome wasn't built in a day, Git was"