4 ms·

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

by sieve 5y ago

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.

crossroadsguy 5y ago
> 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.
- aidenn0 5y ago
  > 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 https://github.com/asciidoctor/asciidoctor/issues/901
- ajkjk 5y ago
  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.
felipelemos 5y ago
Just a nitpick: Pascal is not much older than sh. Maybe a couple of years?
- sieve 5y ago
  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 https://en.wikipedia.org/wiki/Thompson_shell) [2] 1979 (https://en.wikipedia.org/wiki/Bourne_shell https://en.wikipedia.org/wiki/Bourne_shell) [3] 1978 (https://en.wikipedia.org/wiki/C_shell https://en.wikipedia.org/wiki/C_shell)
saimiam 5y ago
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.
- bschwindHN 5y ago
  > 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.
  - cema 5y ago
    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.
  - superbatfish 5y ago
    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.
- Snild 5y ago
  > 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
TeeMassive 5y ago
> 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.
- sieve 5y ago

by sieve 5y ago

crossroadsguy 5y ago

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

aidenn0 5y ago
> 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 https://github.com/asciidoctor/asciidoctor/issues/901
ajkjk 5y ago
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.

felipelemos 5y ago

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

sieve 5y ago
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 https://en.wikipedia.org/wiki/Thompson_shell) [2] 1979 (https://en.wikipedia.org/wiki/Bourne_shell https://en.wikipedia.org/wiki/Bourne_shell) [3] 1978 (https://en.wikipedia.org/wiki/C_shell https://en.wikipedia.org/wiki/C_shell)

saimiam 5y ago

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.

bschwindHN 5y ago
> 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.
- cema 5y ago
  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.
- superbatfish 5y ago
  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.
Snild 5y ago
> 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

TeeMassive 5y ago

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

sieve 5y ago