3 ms·

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

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
- ghusbands 5y ago
  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.
  - Snild 5y ago
    You are technically correct; the best kind of correct. Writing as if they were changes is a little sloppy, though convenient.
sieve 5y ago
> 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 https://www.arqbackup.com/arq_data_format.txt

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

ghusbands 5y ago
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.
- Snild 5y ago
  You are technically correct; the best kind of correct. Writing as if they were changes is a little sloppy, though convenient.

sieve 5y ago

> 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 https://www.arqbackup.com/arq_data_format.txt