Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git is too hard

changelog.com

Post reply on HN
Print view View original

91–100 of 821 posts

Re: Git is too hard

#91

Post by bipson »

What I often experience (see also a lot of comments here):

Some people, however smart, try to force git to do something in particular, without asking first "How can I do x with git" (I don't think I ever had a use case where stackoverflow didn't have a solution for).

Then they end up with a borked repo, everything is confusing (because it should have almost never been in this state), angry at the tool they abused so badly.

Git is solving complex problems, and it obviously has certain idiosyncrasies. But just because you think the developers chose poorly, doesn't necessarily mean git is terrible in the first place (might also be true though, but please prove it by showing a better alternative). I heard mercurial has a lot of fans, but I had a terrible time cleaning up behind colleagues though - everything was easy for them, but they did not know what they were doing and why it was bad. The git branching-workflow helped a lot there.

Often the obvious solution of an outsider is not really a solution.

Could git have named some commands better? Yes, of course. If you don't know what git is doing internally on a checkout, it makes little sense. But this is being worked on.

I would argue that if someone comes up with his very own perfect distributed versioning system intended to be super intuitive and simple, he will in the end also build in complex constructions that make no sense to outsiders that didn't participate in thinking about the complex problem these concepts are trying to solve.

Re: Git is too hard

#92

Post by b212 »

I'm a "senior" dev and here's my git skillset:

  git clone [repo] (download existing project)

  git init (start a new project)

  git checkout -b [branchname] (create a new branch)

  git checkout [branchname] (jump between branches)

  git checkout -- [filename] (reset changes in given file)

  git reset --hard (reset evertyhing)

  git clean -f -d (remove leftovers after reset --hard)

  git status (see changed files)

  git diff (see changed lines)

  git add ./[filename] (prepare file(s) for saving)

  git commit -m [commitname] (save changes)

  git push origin [branchname] (push changes to remote server)

  git merge [branch] (merge two branches)
I've been using these commands exclusively for the last 12 years or so. These are the ones I know by heart. If I was able to get by only using these than it's likely you could also survive knowing nothing more.

Rebase is still confusing at times. I did cherrypicking multiple times, but usually Google that just to be sure.

Squashed a few times, but this I also Google.

Reverted a commit a few times too, Googled.

Changing commit message and unstaging is more common, but still do it so rarely I have to Google it as there's no point in memorising (one day might finally remember them, right now I know it's reset soft and amend, not sure about syntax).

I do not use git pop and git stash because microcommiting is better and less confusing and leaves no trash behind (just my opinion, might be wrong).

Maybe I've missed something but if you're taking it slow and do not make any serious fuckups with git it's all about add/commit/push, 99% of the time. I know I might seem lame to most of you as there are more git ninjas on HN than anywhere else, but I honestly just did not need any other commands and I've been working for companies as big as 500 devs.

It's a whole different story once you do something wrong, my strategy is to think 10x about everything I type after 'git' and never had any issues, but when they happen - I just Google again. Worked every time, so far. I feel although I know shit about git I'm pretty confident using it, I've seen many mid devs who still have trouble with mental models of merging stuff, people merging "dev" branch to feature branches etc. is something that happens to other folks quite often.

To sum things up - I think git is extremely hard if you want to use it from top of your head to fix complicated and not that common issues. If you just want to use it, survive and not necessarily understand all the mechanics behind it - it's as easy as HTML.

I sympathise with the article, though I'm not sure git is to blame here - if you have to revert a branch from remote once in 2 years there's no way you're going to remember how to do that. Without UI you will need to search for the solution every time, and it does not matter what command line tool or version-control system you use.

Re: Git is too hard

#93

Post by Tor3 »

boriselec wrote: post #25
Mayzie wrote: post #18

Earlier quoted context omitted.

What book(s) would you recommend?

https://jwiegley.github.io/git-from-the-bottom-up/

That's the one which quickly got me up and running with Git, and made it easier to get a feel for how to do things.

Re: Git is too hard

#94

Post by dimgl »

zingermc wrote: post #83
ramraj07 wrote: post #38

Earlier quoted context omitted.

I'm not an idiot, but I don't fully understand git. I am coding for a living, and I use git every day. I probably could sit down for a couple of days and fully understand how git works, but I've never needed it, I understand how basic git operations work, and I stay away from commands that I don't understand. With GitHub desktop you don't need to open the command line for any standard operations, I only need to use t…

I've definitely been the victim of my own git hubris. Once, when leaving a job, I decided to copy all of my local WIP branches to the server. I whipped out this fancy --mirror option I had just heard of: git push --mirror $remote Surprise! All branches on the remote repo got wiped. My local refs replaced the refs on the remote. Somehow I found the right commits floating around in the git ether. I was able to recreate…

I get it, but I'm not sure you should fault Git for that. Nothing like that has ever happened to me and I wouldn't use a command I don't know in a critical setting...

Re: Git is too hard

#95

Post by ramraj07 »

ghayes wrote: post #85
ramraj07 wrote: post #38

Earlier quoted context omitted.

I'm not an idiot, but I don't fully understand git. I am coding for a living, and I use git every day. I probably could sit down for a couple of days and fully understand how git works, but I've never needed it, I understand how basic git operations work, and I stay away from commands that I don't understand. With GitHub desktop you don't need to open the command line for any standard operations, I only need to use t…

I'm not sure I follow your logic: why not take a few days to learn the fundamentals of git? I did that a few years back (and I'm not saying I read the source code, just learned about the base concepts from a few blogs and played around with some more advanced commands), and it has paid dividends _every single day for the last several years_. For example, I avoid tracking branches and have started using `git fetch`, `…

I am limited by time on what I can learn, every day I have five other things I'd rather spend my time learning about instead of git. The "git experts" that I know of are no more productive than me and more often than not do annoying things like rewriting commit histories after I made comments in their PRs, that I'm not convinced it's worth the day or two I need to learn it fully. In the end git is not in production, it's just a tool to manage code, I'd rather be an expert on the code than the coding tool. This is probably akin to trying to understand how your car works when all you need it to do is get you to work. Changing tires is about as much as anyone who's trying to be productive should know about their car. Call a mechanic for anything else.

Re: Git is too hard

#96

Post by 8draco8 »

grey-area wrote: post #79
8draco8 wrote: post #16

Earlier quoted context omitted.

The only concept that I can't put into my muscle memory is reverting changes for one file before commit. This is very easy in SVN but for some reason it's not intuitive git (at least for me), why there can't be something like `git revert filename`. Thankfully I have GitKraren that is helping me with things like that.

There is now (as of version 2.23.0), you can use: git restore filename

Thank you that will help me a lot.

Re: Git is too hard

#97

Post by 8draco8 »

rusk wrote: post #20
8draco8 wrote: post #16

Earlier quoted context omitted.

The only concept that I can't put into my muscle memory is reverting changes for one file before commit. This is very easy in SVN but for some reason it's not intuitive git (at least for me), why there can't be something like `git revert filename`. Thankfully I have GitKraren that is helping me with things like that.

‘git checkout filename’ is the equivalent of ‘svn revert filename’

I had no idea that checkout does that to files. In my head checkout was only for manipulating branches and revisions of whole repo

Re: Git is too hard

#98

Post by jodrellblank »

rusk wrote: post #89
oblio wrote: post #68

Earlier quoted context omitted.

We shouldn't need a cheat sheet. We shouldn't need Linus's brain dump to be able to use a tool. The Git UI directly models the Git internal model and that's just bad design. It's a completely leaky abstraction. I can use git all right but the fact that I need about 20 different commands to do my job, 95% of them with extra parameters and almost all of them with names that don't reflect what I want to do from a functi…

I hope I never end up working with you bud. “Where is the code?” “Oh I’m sorry I couldn’t do it because it was hard can I still be paid please?”

I refer to my comment from a couple of days ago: https://news.ycombinator.com/item?id=25080013

Re: Git is too hard

#99

Post by ajuc »

ghayes wrote: post #85
ramraj07 wrote: post #38

Earlier quoted context omitted.

I'm not an idiot, but I don't fully understand git. I am coding for a living, and I use git every day. I probably could sit down for a couple of days and fully understand how git works, but I've never needed it, I understand how basic git operations work, and I stay away from commands that I don't understand. With GitHub desktop you don't need to open the command line for any standard operations, I only need to use t…

I'm not sure I follow your logic: why not take a few days to learn the fundamentals of git? I did that a few years back (and I'm not saying I read the source code, just learned about the base concepts from a few blogs and played around with some more advanced commands), and it has paid dividends _every single day for the last several years_. For example, I avoid tracking branches and have started using `git fetch`, `…

The problem is - if you're not using some feature every month you won't remember how to do it anyway when you finally need to use it.

So there's little point reading about exotic features upfront other than to know they exist. And which features are exotic depends on your workflow.

It would help if git interface was consistent enough to make remembering this stuff easier.

For example I never remember the exact options for git reset because I'm using it just rarely enough to forget them when I need them again.

Re: Git is too hard

#100

Post by vr46 »

There's some core concepts that need to be grokked to not feel stupid, like commit, rebase, pull, fetch, merge, revert, and more important, when you use them and when you don't.

There's a learning curve in understanding version control, not just git. The git manual/handbook covers all of this, including reasoning, but the way that the industry carries on is as if git is a side dish that accompanies the main meal. Git is not like that, it's been here 15 years and deserves investment like a programming language, or a text editor (see Vim/Emacs).

I disagree that you need to understand the internals, but it can prove useful.

Post reply on HN