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

Oh Shit, Git

ohshitgit.com

Post reply on HN
Print view View original

31–40 of 237 posts

Re: Oh Shit, Git

#31

Post by frizlab »

sdevonoes wrote: post #23
5e92cb50239222b wrote: post #18

Earlier quoted context omitted.

Or you can spend some time once to understand how git works, and never run into a similar situation again. git is built on a beautiful and very simple model, and it's easy to unbreak the repository 99% of time if you understand it (and I'm saying this as a very mediocre programmer).

Depends. Sometimes it's easier to tear down everything and start from scratch.

I spend my life in git. I never ever had to just erase everything and clone again. I do not see a situation where it would be needed honestly.

Re: Oh Shit, Git

#32

Post by elsjaako »

hardware2win wrote: post #25
petepete wrote: post #17

Earlier quoted context omitted.

Git was built with a very specific use case and aimed at an extraordinarily technical subset of users. It dominated the world despite the UX flaws, which suggests they really aren't that bad.

I'd say that ppl got used to it and it is good enough + industry standard, so it is hard to migrate to something else Especially if you'd have to lose github, thats the real force If gh migrated to something else, then a lot of ppl would follow

These days when I have to use svn somewhere I use git as a client, because it works better for me.

If you prefer you can use mercurial as a git client in the same way.

Most of my git use stays local on my PC, uploading it to github or gitlab or whatever is a secondary concern for me.

Re: Oh Shit, Git

#33

Post by rkangel »

petepete wrote: post #17
danjac wrote: post #4

Git is a reminder why even the best minds in software development sometimes really should talk to UX/UI people.

Git was built with a very specific use case and aimed at an extraordinarily technical subset of users. It dominated the world despite the UX flaws, which suggests they really aren't that bad.

I'd argue the opposite - that the model was so good and so much better than anything else that it was adopted despite the UI/UX flaws. Things can be good, have a flaw and still be considered good. That doesn't mean that we pretend the flaw doesn't exist.

Re: Oh Shit, Git

#35

Post by chairmanwow1 »

benreesman wrote: post #24

It always amuses me that when Linus presents git to “the Google audience” they objected to the complexity, those people are in fact elite, but measured against what? The TailScale people? The TS people are ex-Google in some places and early-Nix in others, either way no one to fuck with. I’m frustrated if I take a day to work out some something that Jeff Dean mentioned to, uh, a friend, and it took me a day to work it…

I honestly don’t understand the context around this comment or how it relates to the article

Re: Oh Shit, Git

#36

Post by bhrgunatha »

somewhereoutth wrote: post #15

My mental model of a git repo is basically a bramble bush with labels on it. The bramble stems and branches are the commit history (which may join and well as split, unlike a bramble). The labels are stuck to particular bits of the bramble. Some labels are even stuck to other labels! You can move the labels around, and you can glue extra bits of bramble to the tips of what you have. You can even hack about with the b…

Learning the underlying model behind git is well worth the effort. For me watching Steve Smith's talk - Knowledge is Power: Getting out of Trouble by Understanding Git - was a lightbulb moment.

Here's a 2019 presentation of that talk.

https://www.youtube.com/watch?v=fHLcZGi3yMQ

Re: Oh Shit, Git

#37

Post by samwillis »

kasey_junk wrote: post #27
petepete wrote: post #17

Earlier quoted context omitted.

Git was built with a very specific use case and aimed at an extraordinarily technical subset of users. It dominated the world despite the UX flaws, which suggests they really aren't that bad.

It dominated the world because GitHub was better than BitBucket and had more generous free levels. If only that wasn’t the case we’d all be using a sensible source control system now instead of one where people repeatedly say things like “if you just learn the underlying model…”

> GitHub was better than BitBucket and had more generous free levels

GitHub for many years only had free public repos, not privet, BitBuckets USP was that you could have privet repositories for free.

GitHub "won" because of the social aspect around it and the tooling for open source projects - it never had more generous free levels.

Re: Oh Shit, Git

#38

Post by raju »

While I'd like to think that this is _somewhat_ useful, I am a little hesitant. The issue I see with these bite-sized recipes is that there is no context, no place for nuance, and no hint that the behavior you see might be different for a variety of reasons.

Take the following for example:

> Oh shit, I need to change the message on my last commit!

> git commit --amend

It's important to realize here that if you are simply trying to edit the last commit message, you *should not* have anything in your index (that is, staged). Otherwise those changes will be recorded in the amended commit! What Git does is essentially move all the changes recorded in the commit you are amending _into_ the index, and then run `git commit -m ` ... so if you have files in there, those will get mixed up with the ones in the commit.

Here's another one:

> Oh shit, I accidentally committed to the wrong branch!

> A lot of people have suggested using `cherry-pick` for this situation too, so take your pick on whatever one makes the most sense to you!

Umm ... No! The solution proposed (with `git reset --soft`) and a cherry-pick are NOT the same! Not even close! You will produce two completely different histories.

This final one, given when this page was written, _may be_ understandably incorrect

> Oh shit, I need to undo my changes to a file!

> `git checkout [saved hash] -- path/to/file`

There is the introduction of a new command called `git-restore` (https://git-scm.com/docs/git-restore) that (thankfully) is named more appropriately—it "restores" a file. I wrote a thread on it on Twitter, so if you are curious perhaps this will help: https://twitter.com/looselytyped/status/1501934009370042371

*Shameless plug for my book*

My book, Head First Git, was published by O'Reilly this January. I posted a submission here on HN about it https://news.ycombinator.com/item?id=30072348 so if you want any details feel free to peruse that.

Some links:

- Amazon: https://www.amazon.com/Head-First-Git-Learners-Understanding...

- O'Reilly's online platform (Needs subscription): https://learning.oreilly.com/library/view/head-first-git/978...

- Companion website: https://i-love-git.com/

(Edited for formatting)

Re: Oh Shit, Git

#40

Post by kasey_junk »

samwillis wrote: post #37
kasey_junk wrote: post #27

Earlier quoted context omitted.

It dominated the world because GitHub was better than BitBucket and had more generous free levels. If only that wasn’t the case we’d all be using a sensible source control system now instead of one where people repeatedly say things like “if you just learn the underlying model…”

> GitHub was better than BitBucket and had more generous free levels GitHub for many years only had free public repos, not privet, BitBuckets USP was that you could have privet repositories for free. GitHub "won" because of the social aspect around it and the tooling for open source projects - it never had more generous free levels.

BitBucket limited the number of repos you could have while GitHub allowed you to have as many as you wanted so long as they were public. Which had the (intended?) effect of making it more useful socially.
Post reply on HN