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

Things I wish everyone knew about Git (Part I)

blog.plover.com

Post reply on HN
Print view View original

11–20 of 200 posts

Re: Things I wish everyone knew about Git (Part I)

#11

Post by lisper »

> But if I were going to tell everyone just one more thing, it would be:

> It is very hard to permanently lose work.

Unfortunately, this is not quite true. Git checkout will silently and irretrievably clobber all the changes in your working tree [UPDATE: if you do 'git checkout [path]', but that is not an uncommon thing to do.]

It is true that it is very hard to lose work that you have committed. But even this is not necessarily a good thing if, for example, you accidentally committed something that contains sensitive information that you want to delete. (And God help you if you have pushed such a change upstream.)

The sad fact of the matter is that while the underlying data structures are beautiful and tremendously useful, the UI/UX is a dumpster fire.

It's actually not that hard to put a different UI/UX on top of the core. I'm kind of surprised no one has done this.

Re: Things I wish everyone knew about Git (Part I)

#12

Post by intrepidhero »

> But if you try to understand the commands without the model, you will suffer, because the commands do not make sense.

I've read this about git several times and certainly felt it. My question is why hasn't anyone come along and fixed it? Git has the plumbing vs. porcelain separation. Why hasn't someone written new porcelain that makes git as intuitive as mercurial, subversion, etc? This seems like a similar situation as dpkg/apt. The underlying design has been settled but we desperately need a better interface.

> Git has an elegant and powerful underlying model based on a few simple concepts

My second question is, if the underlying model is so f*cking elegant, how did it lead to such a confusing interface? This isn't so much me griping about git (although I am) but more a curious case for design theory. Would love to read serious analysis. I can't offhand think of another piece of software where "the model is elegant but the interface is confusing" is such a common critique.

Re: Things I wish everyone knew about Git (Part I)

#13

Post by mytailorisrich »

If you're going to move files around, it's worth experimenting with one file first without doing any change in order to make sure you do it in a way that preserve history.

There is 'git mv' for that. I have found the best way is to create new directories then use 'git mv' on the files.

Re: Things I wish everyone knew about Git (Part I)

#14

Post by crispyambulance »

buzzwords wrote: post #5

I wonder how many hours have been wasted on fixing mistakes made on git. Recently, I watch a friend spend two days try and figure out what the junior Devs have done with commits and branches

Yeah, that's the tragic thing about git. It's so easy to get the wrong idea or fumble on the easily forgettable garbage CLI semantics and make mistakes. Even experienced people make mistakes if they try do something that's different from their daily grind.

To make it worse, correcting mistakes ALSO is something that's not done regularly-- so that becomes an obstacle as well.

Re: Things I wish everyone knew about Git (Part I)

#16

Post by macintux »

This thread from earlier this week (“Oh shit, Git”) includes discussion of many similar resources.

https://news.ycombinator.com/item?id=31874308

Some that looked interesting:

* https://learngitbranching.js.org/

* https://github.com/blog/2019-how-to-undo-almost-anything-wit...

* https://github.com/k88hudson/git-flight-rules

Re: Things I wish everyone knew about Git (Part I)

#17

Post by karmakaze »

> Git has an elegant and powerful underlying model based on a few simple concepts:

    Commits are immutable snapshots of the repository
    Branches are named sequences of commits
    Every object has a unique ID, derived from its content
I would list them as:

    Every object has a unique ID, derived from its content
    - and every commit id depends on its ancestors' commit ids
    Each commit has an associated snapshot (file tree) of the repository
    A branch is a named reference to a commit
    - the referenced commit changes with addition/rebase/amend of commit(s)
Not quite as compact or elemental but a usably granular mental model.

If you want to learn how git works you can read about it, or merely look at the small text files inside a .git directory.

Re: Things I wish everyone knew about Git (Part I)

#18

Post by hbn »

The only thing that makes me competent enough to do most normal day-to-day stuff in git is the built-in git UI in JetBrains IDEs.

It's super intuitive, there's buttons that say exactly what they'll do without me having to worry what underlying commands it's running, and the best part is the merge conflict resolution UI that lets you go file by file and has a 3-pane split for existing changes, merged file, and incoming changes. You can select the arrows that are drawn from one pane into the center to bring those changes into it, X to ignore those changes, and the center is completely interactive like any other text editing area in the IDE so you can just copy paste from each side and fix it yourself.

I basically don't ever bother with git from the command line.

Re: Things I wish everyone knew about Git (Part I)

#20

Post by throw7 »

Isn't "naming things" one of those "hard things" to do well in computer science?

It seemed to me, linus and the initial git architects just kind of slapped names on operations as features grew organically over top of the model. To early adopters, all of it made sense. Yeah, someone new looking in from the top down will be bewildered.

Post reply on HN