8 ms·

I have never understood the claim that git is hard. the docs are good and there are plenty of examples online. feels the same when people say, "jq is hard i us

I have never understood the claim that git is hard. the docs are good and there are plenty of examples online. feels the same when people say, "jq is hard i use python instead" like ok

CuriouslyC 1y ago
My perspective, git isn't hard, but coordinating git workflows in teams with a merge backlog is a real pain in the ass.
bqmjjx0kac 1y ago
I have burned git into my brain, so it's no longer hard to me. OTOH, I only pull out jq once every six months or so, and I just barely scrape by every time.
- fernandotakai 1y ago
  and i honestly would rather parse json inside ipython and then move to a script, than keep invoking `| jq` time and time again.
largbae 1y ago
I've worked with many folks over the years after learning myself... The feeling of complexity comes from not yet understanding that commits are just sets of changes to files. They are then thrown off the scent by new terms like origin clone vs push and pull, merge vs rebase, HEAD increment notation vs other commit hashes. Once people start with a local understanding of using git diff and git add -p they usually get the epiphany. Then git rebase -i and git reflog take them the rest of the way. Then add the distributed push and fetch/pull concepts.
thefifthsetpin 1y ago
I've long been facinated by how bimodal understanding of git is. I'm one of the lucky ones to whom it came naturally, but there's clearly a large population who finds git challenging even after investing significant time and effort into learning it. I don't see this anywhere nearly as drastically with other tools.
- koiueo 1y ago
  There are simply people who've rtfm and people who haven't
  - Agingcoder 1y ago
    The git documentation is one of the nastiest docs ever just like the whole git ui. It’s technically entirely correct, but won’t help you understand how it works in any way. It’s exactly like folks in 1995 telling you to rtfm when you’re trying to install Linux from a floppy disk. It’s doable, but annoying, and it’s not that easy.
    - koiueo 1y ago
      That's really unexpected. To me, git documentation was one of the best cleanest official docs I've ever read. Just in case, I'm talking about the Pro Git book [0]. I remember reading it on my kindle while commuting to office by train. It was so easy to understand, I didn't even need a computer to try things. And it covers everything from bare basics, to advanced topics that get you covered (or at least give you a good head start) if you decide to develop your own jujutsu or kurutu or whutuvur. [0] https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2
      - Agingcoder 1y ago
        This is exactly what I meant. https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-N... The book says that ‘ To really understand the way Git does branching, we need to take a step back and examine how Git stores its data’ then it starts talking about trees and blobs. At that point you’ve lost almost everyone. If you have a strong interest in vcs implementation then fine, otherwise it’s typically the kind of details you don’t want to hear about. Most people won’t read an entire book just to use a vcs, when what they actually want to hear is ‘this is a commit graph with pointers’. I agree with you : the information is there. However I don’t think you can in good faith tell most people to rtfm this, and that was my point.
metabagel 1y ago
From time to time, I end up in a state which I don't know how to recover from, and it's very frustrating to have to take an hour or two from my real work in order to try to figure out how to get out of that state. https://roadrunnertwice.dreamwidth.org/596185.html https://roadrunnertwice.dreamwidth.org/596185.html
- gorjusborg 1y ago
  The reflog is the failsafe. It is the tool that fixes all the scary states, as it keeps a journal of the states of each ref in the repo (like branch heads). You can see where you were and hard reset back, no matter what state you are in.
  - steveklabnik 1y ago
    If you like the reflog, you'll love jj's oplog: it's like the reflog, but for all repository state changes.
litenboll 1y ago
I think what people usually mean is "scary" or "it's easy to mess up". Git is very easy to use until you mess up, then it can become complicated, and certain actions may have devastating consequences. Two examples from recent memory: Someone merged the develop branch into their branch, then changed their mind and reverted the merge commit specifically (i.e. reversing all the incoming changes), then somehow merged all of this into the develop branch, undoing weeks of work without noticing. I had to go in and revert the revert to undo the mistake. Yes they messed up, but these things happen with enough people and time. Another very interesting issue that happened to a less technical person on the team was that their git UI somehow opened the terminal in the wrong folder. They then tried to run some command which made git suggest to run 'git init', creating another git repo in that wrong location. Fast forward some days and we had an issue where people had to clean their repos, so I was in a call with the person helping them run the clean command. The UI opened the wrong location again, I helped them put in the command and it started cleaning. The problem was that this git repo was essentially at the top level on their disk, and since was a fresh repo every single file was considered a new file so it tried to delete EVERYTHING on their disk. This was of course mostly my fault for not running git status before the clean command, but this potential scenario was definitely not on my mind.
- Nashooo 1y ago
  I mean. How can it be scary when you have git reflog.
  - steveklabnik 1y ago
    The reflog doesn't capture everything. jj's oplog does. An example of something that the reflog isn't going to capture is a git reset --hard losing your unstaged changes, whereas the equivalent flow and commands in jj would allow you to get those contents back.
    - Nashooo 1y ago
      That makes sense
    - 1y ago
Agingcoder 1y ago
So based on my experience teaching git ( I remember a cvs to git migration …) , reality tells me people find git difficult. Now, once you teach them it’s a commit graph with names, some of them floating, some people get it. The thing is, not everyone is comfortable with a commit graph, and most people are not - just like people get lists and arrays but graphs are different. So I agree with you on principle ( it shouldn’t be difficult), but most people don’t have a graph as a mental model of anything, and I think that’s the biggest obstacle.
steveklabnik 1y ago
Even though I never found git hard, I find jj better.
stouset 1y ago
I am (was) a git expert. I’ve written a git implementation. I’ve used it since shortly after it was first announced. Git has lots of sharp edges that can get hairy or at least tedious really rapidly. You have to keep a ton of random arcana in working memory at all times. And a bunch of really useful, lovely workflows are so much of a pain in the ass that you don’t even conceive of doing them. I learned jj in one day and never went back.
- digdugdirk 1y ago
  ^^^ This aspect of the arcana one is required to keep in working memory is an issue that's glossed over far too frequently. I understand that git is a developer focused tool, but requiring a user to keep a constant mental burden in working memory completely bars non-developers from using git in any legitimate way. I'm not a welder or a metalworker, but I do know how to weld. I use a welder a handful of times per year when I need/want to. Welding is dangerous, and achieving excellence is a difficult and long road. But I can use the same tools as a pro and still get a few pieces of metal stuck together without having to relearn and restudy the whole system each time something goes wrong. I haven't used jj in anger yet, but I think it might at least be approaching that style of developer tool.
caconym_ 1y ago
I think people who grasp the basic idea of a commit graph and approach it in terms of "this is how I want to manipulate the graph, what are the tools that will allow me to do this?" find it easy, and people who approach it in terms of building a cookbook of commands that comprise a workflow don't.
- stouset 1y ago
  I am somebody who deeply cares about my commit graph. I want to maintain clean history, and I want to regularly amend previous commits (until merged) in order to tell a coherent story about development. I want to keep unrelated commits on separate branches, so they can be reviewed and merged independently. I understand how to do these things, but git’s interaction model makes it tedious at best and hard at worst. jj’s interaction model makes these things simple, straightforward, and obvious in the overwhelming majority of cases.
bigstrat2003 1y ago
Parsing json is so much easier with Python than jq, it's not even funny. That doesn't mean jq is useless, because sometimes keeping it in the shell is the best option. But in terms of ease of use jq is shit.
hitarpetar 1y ago
that's okay, it doesn't need to be your personal experience. you just need to understand that "git gud" is not a sustainable or intelligent mantra for tool design and selection

I have never understood the claim that git is hard. the docs are good and there are plenty of examples online. feels the same when people say, "jq is hard i use python instead" like ok

CuriouslyC 1y ago

My perspective, git isn't hard, but coordinating git workflows in teams with a merge backlog is a real pain in the ass.

bqmjjx0kac 1y ago

I have burned git into my brain, so it's no longer hard to me. OTOH, I only pull out jq once every six months or so, and I just barely scrape by every time.

fernandotakai 1y ago
and i honestly would rather parse json inside ipython and then move to a script, than keep invoking `| jq` time and time again.

largbae 1y ago

I've worked with many folks over the years after learning myself... The feeling of complexity comes from not yet understanding that commits are just sets of changes to files. They are then thrown off the scent by new terms like origin clone vs push and pull, merge vs rebase, HEAD increment notation vs other commit hashes. Once people start with a local understanding of using git diff and git add -p they usually get the epiphany. Then git rebase -i and git reflog take them the rest of the way. Then add the distributed push and fetch/pull concepts.

thefifthsetpin 1y ago

I've long been facinated by how bimodal understanding of git is. I'm one of the lucky ones to whom it came naturally, but there's clearly a large population who finds git challenging even after investing significant time and effort into learning it. I don't see this anywhere nearly as drastically with other tools.

koiueo 1y ago
There are simply people who've rtfm and people who haven't
- Agingcoder 1y ago
  The git documentation is one of the nastiest docs ever just like the whole git ui. It’s technically entirely correct, but won’t help you understand how it works in any way. It’s exactly like folks in 1995 telling you to rtfm when you’re trying to install Linux from a floppy disk. It’s doable, but annoying, and it’s not that easy.
  - koiueo 1y ago
    That's really unexpected. To me, git documentation was one of the best cleanest official docs I've ever read. Just in case, I'm talking about the Pro Git book [0]. I remember reading it on my kindle while commuting to office by train. It was so easy to understand, I didn't even need a computer to try things. And it covers everything from bare basics, to advanced topics that get you covered (or at least give you a good head start) if you decide to develop your own jujutsu or kurutu or whutuvur. [0] https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2
    - Agingcoder 1y ago
      This is exactly what I meant. https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-N... The book says that ‘ To really understand the way Git does branching, we need to take a step back and examine how Git stores its data’ then it starts talking about trees and blobs. At that point you’ve lost almost everyone. If you have a strong interest in vcs implementation then fine, otherwise it’s typically the kind of details you don’t want to hear about. Most people won’t read an entire book just to use a vcs, when what they actually want to hear is ‘this is a commit graph with pointers’. I agree with you : the information is there. However I don’t think you can in good faith tell most people to rtfm this, and that was my point.

metabagel 1y ago

From time to time, I end up in a state which I don't know how to recover from, and it's very frustrating to have to take an hour or two from my real work in order to try to figure out how to get out of that state. https://roadrunnertwice.dreamwidth.org/596185.html https://roadrunnertwice.dreamwidth.org/596185.html

gorjusborg 1y ago
The reflog is the failsafe. It is the tool that fixes all the scary states, as it keeps a journal of the states of each ref in the repo (like branch heads). You can see where you were and hard reset back, no matter what state you are in.
- steveklabnik 1y ago
  If you like the reflog, you'll love jj's oplog: it's like the reflog, but for all repository state changes.

litenboll 1y ago

I think what people usually mean is "scary" or "it's easy to mess up". Git is very easy to use until you mess up, then it can become complicated, and certain actions may have devastating consequences. Two examples from recent memory: Someone merged the develop branch into their branch, then changed their mind and reverted the merge commit specifically (i.e. reversing all the incoming changes), then somehow merged all of this into the develop branch, undoing weeks of work without noticing. I had to go in and revert the revert to undo the mistake. Yes they messed up, but these things happen with enough people and time. Another very interesting issue that happened to a less technical person on the team was that their git UI somehow opened the terminal in the wrong folder. They then tried to run some command which made git suggest to run 'git init', creating another git repo in that wrong location. Fast forward some days and we had an issue where people had to clean their repos, so I was in a call with the person helping them run the clean command. The UI opened the wrong location again, I helped them put in the command and it started cleaning. The problem was that this git repo was essentially at the top level on their disk, and since was a fresh repo every single file was considered a new file so it tried to delete EVERYTHING on their disk. This was of course mostly my fault for not running git status before the clean command, but this potential scenario was definitely not on my mind.

Nashooo 1y ago
I mean. How can it be scary when you have git reflog.
- steveklabnik 1y ago
  The reflog doesn't capture everything. jj's oplog does. An example of something that the reflog isn't going to capture is a git reset --hard losing your unstaged changes, whereas the equivalent flow and commands in jj would allow you to get those contents back.
  - Nashooo 1y ago
    That makes sense
  - 1y ago

Agingcoder 1y ago

So based on my experience teaching git ( I remember a cvs to git migration …) , reality tells me people find git difficult. Now, once you teach them it’s a commit graph with names, some of them floating, some people get it. The thing is, not everyone is comfortable with a commit graph, and most people are not - just like people get lists and arrays but graphs are different. So I agree with you on principle ( it shouldn’t be difficult), but most people don’t have a graph as a mental model of anything, and I think that’s the biggest obstacle.

steveklabnik 1y ago

Even though I never found git hard, I find jj better.

stouset 1y ago

I am (was) a git expert. I’ve written a git implementation. I’ve used it since shortly after it was first announced. Git has lots of sharp edges that can get hairy or at least tedious really rapidly. You have to keep a ton of random arcana in working memory at all times. And a bunch of really useful, lovely workflows are so much of a pain in the ass that you don’t even conceive of doing them. I learned jj in one day and never went back.

digdugdirk 1y ago
^^^ This aspect of the arcana one is required to keep in working memory is an issue that's glossed over far too frequently. I understand that git is a developer focused tool, but requiring a user to keep a constant mental burden in working memory completely bars non-developers from using git in any legitimate way. I'm not a welder or a metalworker, but I do know how to weld. I use a welder a handful of times per year when I need/want to. Welding is dangerous, and achieving excellence is a difficult and long road. But I can use the same tools as a pro and still get a few pieces of metal stuck together without having to relearn and restudy the whole system each time something goes wrong. I haven't used jj in anger yet, but I think it might at least be approaching that style of developer tool.

caconym_ 1y ago

I think people who grasp the basic idea of a commit graph and approach it in terms of "this is how I want to manipulate the graph, what are the tools that will allow me to do this?" find it easy, and people who approach it in terms of building a cookbook of commands that comprise a workflow don't.

stouset 1y ago
I am somebody who deeply cares about my commit graph. I want to maintain clean history, and I want to regularly amend previous commits (until merged) in order to tell a coherent story about development. I want to keep unrelated commits on separate branches, so they can be reviewed and merged independently. I understand how to do these things, but git’s interaction model makes it tedious at best and hard at worst. jj’s interaction model makes these things simple, straightforward, and obvious in the overwhelming majority of cases.

bigstrat2003 1y ago

Parsing json is so much easier with Python than jq, it's not even funny. That doesn't mean jq is useless, because sometimes keeping it in the shell is the best option. But in terms of ease of use jq is shit.

hitarpetar 1y ago

that's okay, it doesn't need to be your personal experience. you just need to understand that "git gud" is not a sustainable or intelligent mantra for tool design and selection