Hacker News Reader

Comment by sieve | Hacker News Reader

I used Fossil for a bit a few years ago. A nice, self-contained tool that stores everything in a single file that can be easily backed up.

Had to give up on it because using two different revision control systems became inconvenient after a while. But I regret the loss of Mercurial, after having used it for a decade or so, more than that of Fossil.

It always bothered me how a user-hostile piece of software like git rapidly took over the world. But then I remembered sh and bash and realized that someone thought that these softwares should be designed the way they were decades after Pascal and Lisp and hundreds of other sensible languages came into being, and they took over the world too.

View on HN

I’m so relieved to hear someone articulate this sentiment that _git_ is user hostile. Sometimes it feels like TINA to git in the modern world.

At a conceptual level, so much of the more esoteric parts of git makes little to no sense. E.g., rebasing. I don’t completely understand what it is supposed to achieve.

Even vi, with its own idiosyncrasies, is eventually grokkable once you understand that vi key sequences are an expression of an action you want to take.

Git? Nothing makes sense. There is no connection (that I can nail) between its many features and how we think about and articulate what we want to do with a repo.

It’s success is so strange to me.

> esoteric parts of git makes little to no sense. E.g., rebasing

Gotta be honest, rebasing is not an "esoteric" part of git.

You would be doing yourself a service to read up on how git and its internals work. If you're a software developer, chances are high that your workplace, or a library your workplace uses will be managed via git and you'll have to use it. Might as well be ready for that, because if you put in just a little bit of effort to understand it, it becomes an easy tool to use.

With an effort, git becomes a familiar tool to use, but does it every become easy to use? There is a reason people have called it user-hostile.

I don’t think knowing the “internals” is really necessary. I like git and use rebase frequently. But I know almost nothing about the internals.

To me, it’s just a convenient way to keep track of big stacks of patches. That’s enough to understand rebase and most other commands.

> E.g., rebasing. I don’t completely understand what it is supposed to achieve.

I recognize that this is just one example of probably many things you dislike about git, and I will not be able to change your mind about it, but:

Rebasing is essentially the user saying "actually, I wanted to make these changes on top of this different base". This is useful if you perhaps started some work on the wrong branch, or just want to test your change on top of the most recent upstream code.

> Nothing makes sense.

I think there are two key realizations to understanding git:

1. It's a directed acyclic graph. That's a very nice data structure to think and reason about.

2. Everyone can have their own version of this graph, so committing a change and sharing it with others are two different operations (and fetching others' changes is yet another).

With those things in mind:

* git rebase copies an arm of the graph and grafts it onto a different starting node

* git cherry-pick copies an arbitrary node in the graph

* git push shares your local additions to the graph with others (usually through a server)

* git fetch updates your local graph (usually from a server)

* git merge joins two arms of the graph, so that one can enjoy the changes from both at the same time

Git's graph is of complete versions, but much of your text talks about it like it's a graph of changes. git rebase analyses an arm of the graph, turns it into a set of changes, tries to work out what those changes would look like if they were attached elsewhere, and then produces that.

It doesn't sound as simple that way, but it's important to keep in mind that git does not track changes and instead rederives them continually.

You are technically correct; the best kind of correct. Writing as if they were changes is a little sloppy, though convenient.

> At a conceptual level, so much of the more esoteric parts of git makes little to no sense.

I see git as a reluctant marriage between two disparate halves: the CLI and the ODS (on-disk structure). There might be technical reasons (and baggage) behind why the ODS is the way it is, but I don't see why the CLI is the way it is.

Outside of the time I spent, some years back, writing code to verify the porting of some mercurial repositories to git, I have no desire to look at the internals of git. Last year, I wrote a tool to query my backups stored by a software that adopted some of its ideas from git,[1] and it was not a pleasant experience. Coincidentally, that software too is just as bad at user interfaces as git is.

[1] https://www.arqbackup.com/arq_data_format.txt

> It always bothered me how a user-hostile piece of software like git rapidly took over the world.

After almost 7 years on git I have given up on getting git and I stick to what that XKCD comic said - remember some commands and just keep syncing. It felt one has to make it into a masochistic exercise to understand it.

I feel similar about Markdown (though I won't call it user hostile). Because there were and there are better and accessible/uncomplicated alternatives.

> I feel similar about Markdown (though I won't call it user hostile). Because there were and there are better and accessible/uncomplicated alternatives.

I don't know; all of the lightweight markup formats are a mess. AsciiDoc/AsciiDoctor is almost great but they seem to have completely borked escaping of inline punctutation[1]

Restructured Text is very "meh" but is better than markdown because directives at least make it more sanely extensible. The downside is it's missing lots of features in its core becase "you can just use a directive"

Markdown was actually pretty good for its original purpose (write html with fewer html tags), but completely falls down for its current common use case (untrusted user input, where you won't allow the user to fallback on html).

1: https://github.com/asciidoctor/asciidoctor/issues/901

I'm eh about Git but .. I love markdown. Sure it has some rough edges but it is such a good idea, and I'm so glad it caught on everywhere.

> It always bothered me how a user-hostile piece of software like git rapidly took over the world.

Why people bother getting a passport, going to an airport, going through security and sharing the ride squeezed along with hundreds of other passengers? Because the alternatives suck in comparison. My last job was one of those corporations that refused to use git because "our devs don't like CLI and git is not as intuitive as Team Foundation". Thankfully after having prospect employees and consultants laughed in their face during interviews they got the message and they switched. But those two years I had to work without git were very depressing.

Here are the reasons git was very quickly adopted:

* Better history aka not everything is a linear list of commits. Merging used to be only comparing naively two file filesystems. There was no notion of checking if changes were already applied. Now merging is reduced to the lowest amount of conflict possible; assuming you know are working along the hash enforced DAG. It was so hard that there used to people called integrators solely dedicated to merge the work of others; they still exist in some projects such as the Linux kernel but they are part of the approval process, not merging itself.

* Centralization sucked and the very notion of distributed version control didn't even exist.

* Branches are cheap. Remember, at the time there used to be flame wars about branches. This really made prototyping hard and inefficient and the only way was to copy the whole project.

* Speed. Centralized systems are inherently slow because the fact that everything is done relative to a server means that nearly every operation involve an online communication and processing from a remote machine. Git is instantaneous for 99% of the commands entered. Being fast also helps developers to not take shortcuts and making sure that what they push is clean and well divided in small and intelligible commits.

* Extreme redundancy. Having the full historic means not having to worry about "the server" getting hacked or the backups failing.

* Flexibility. How do I stash some temporary changes? How do I edit my history before pushing? How do I commit only a few lines at a time? How to I apply the changes of a few selected commits? How do I apply and check a patch file?

* Simple data structures and abstractions. There is no incompatible database schema involved here. Content is addressed and verified by hashes who reference other hashes. A 2005 git repository is still readable in 2021 and beyond. New tools and framework can and has been built around git for that very reason. Other CVS have to do their own mediocre versions.

Most of the reasons you provide apply to DVCSes in general, quite a few of which predate git.

Mercurial too has its genesis in the BitKeeper fiasco and saw an initial release the same month as git. GNU Bazaar saw a release the previous month. Fossil was released the next year.

However, git has all those features; whereas each of the other DVCSes had only a couple of them.

That is what made git successful.

The git cli is, comparatively, a lot easier to grok than it was at the start.

One thing about software, once you've had a (bad) first impression it is very hard to reformulate your opinion.

If the grandparent is lucky enough to find an advocate for git, who is willing to spend time with them, perhaps their opinion might change.

Just a nitpick: Pascal is not much older than sh. Maybe a couple of years?

I think you are referring to Thompson's version?[1] I am referring to Bourne's.[2] Even Joy's shell is older than that one.[3]

[1] 1971 (https://en.wikipedia.org/wiki/Thompson_shell)

[2] 1979 (https://en.wikipedia.org/wiki/Bourne_shell)

[3] 1978 (https://en.wikipedia.org/wiki/C_shell)

Reply on news.ycombinator.com