Visual Git Cheat Sheet • Hacker News Board

Re: Visual Git Cheat Sheet

#41

Post by oa335 » Sun, Sep 19, 2021, 6:02 PM UTC

pdimitar wrote: post #36

jollybean wrote: post #32

Earlier quoted context omitted.

It's not just a leaky abstraction, there is no abstraction! It's the opposite of user-centric design, like a car with no body where you adjust the gasoline pump, the transmission, the amount of oil etc. yourself. There's an underlying model, which is tricky but not rocket science - and all actions on that model can have a bunch of non-obvious state changes and side-effects. It's just complicated enough that it's hard…

Could you please post links to those animations? They could be hugely useful.

Seconded, I would also like to see those animations.

Re: Visual Git Cheat Sheet

#42

Post by jcourt1 » Mon, Sep 20, 2021, 6:39 AM UTC

treesprite82 wrote: post #33

jcourt1 wrote: post #30

Why isn’t git fetch included? Having worked with a quite a lot of developers who don’t understand git, many of whom know so many things I don’t when it comes to so many other domains of dev knowledge, it always astonishes me that people don’t understand what is happening underneath when they do a git pull. I feel like the two main reasons people don’t understand git is that they start by using a GUI instead of starti…

`git fetch` is included - note that you have to click the other columns to see commands relating to them.

My bad. It looks quite a useful reference but suspect it would be overwhelming if you haven’t already understand the key ideas.

My point was really that understanding git doesn’t need to be overly complicated in the end, if you just focus on key concepts, such as the notion of git fetch updating the remote branches within the local repository (and hence status being a reflection of that)

Re: Visual Git Cheat Sheet

#43

Post by dspillett » Mon, Sep 20, 2021, 4:53 PM UTC

pc86 wrote: post #34

dspillett wrote: post #28

Earlier quoted context omitted.

> my main gripe about git is the lack of a linear rev number for master Unless you are using git as a centralised SCM, the concept of a linear revision doesn't quite match up. Of course many workflows between different branch and people do eventually end up with there being a "master master" (or a main main to use more up-to-date terminology), and workflows for single dev projects naturally do, perhaps in those cases…

Most people are using git in a centralized fashion whether they realize it or not.

That is a very correct point.

Though it isn't git's failing when people use a distributed SCM in a centralised manner and expect it to be optimised as such!