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

Oh shit, git (2016)

ohshitgit.com

Post reply on HN
Print view View original

131–140 of 280 posts

Re: Oh shit, git (2016)

#131

Post by gjm11 »

rusk wrote: post #103
masklinn wrote: post #68

Earlier quoted context omitted.

Meh. Git has a shitty UI when you start with, and it still has a shitty UI years down the line. The underlying model is neat and interesting, but that you have to know it to find any usability or elegance is an indictment.

Hence the name I guess ... yeah it's ugly and annoying but you're stuck with it because it's great. Kind of like Linus himself I guess ... I wonder if that's the joke.

> I wonder if that's the joke.

Yup. According to Wikipedia, Linus said: "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."

Re: Oh shit, git (2016)

#133

Post by q3k »

ghiculescu wrote: post #132

> git reset HEAD~ --hard Seems fairly magical compared to other stuff here. To me at least. Can anyone briefly explain what it does?

HEAD~ means 'the second to last commit in the current branch' (ie. the second to last when you `git log`).

git reset means 'point the current branch to this commit instead of wherver it's pointing now' (branches in git are just pointers to commits)

git reset --hard means 'also reset the state of the checkout and staging area to be in sync with the commit'

Thus, the entire spell means 'reset the current branch to make it point the the seecond-to-last-commit, also ensure my current checkout and staging area are in sync to that', or, in other words, fully forget and drop the latest commit.

Re: Oh shit, git (2016)

#134

Post by rich-tea »

voltagex_ wrote: post #59
rich-tea wrote: post #27

Earlier quoted context omitted.

Git is just for programmers. It was made by and for kernel developers, no less. There are better tools for other people. If you don't care what a DAG is, you will never understand what git is or what it's for. No arguments. Git is a tool for building a DAG. If you don't need a DAG you don't need git.

I know, I know, don't reply to the trolls, but at least this troll made me remember some things I'd seen. Git for writers: https://medium.com/@sayhellotovanessa/git-for-writers-write-... > There are better tools for other people. Such as?

Subversion. Or some special purpose versioning system like "track changes".

Re: Oh shit, git (2016)

#135

Post by gpvos »

One thing that I had been looking for for a long time, but never could find, was a description of the several syntaxes you can use to refer to specific commits. Lots of git tutorials use these magic incantations, but none point you to this crucial bit of explanation.

Recently I discovered that it is found under "git help revisions".

Re: Oh shit, git (2016)

#136

Post by rich-tea »

otikik wrote: post #122
rich-tea wrote: post #5

Git is not hard. It's very simple. But people learn it the wrong way. You have to learn it from the DAG up. If you cannot grasp how the DAG works you'll forever be reading and writing articles like this one which do not help you to learn. This is a horrible article. You should not bookmark it or use it. If you're not a programmer, you shouldn't use git. If you are a programmer, do yourself a favour and spend a day go…

The gatekeeping is strong on this one.

Is it also gatekeeping to say that emacs is for programmers? What about C++?

I don't keep any gates. Please come in and learn how to program. I love it and you might do too. But just understand that git is through this gate. It's not "out there".

Re: Oh shit, git (2016)

#137

Post by drchickensalad »

aldanor wrote: post #126
jolmg wrote: post #66

Earlier quoted context omitted.

I use the CLI for my daily work just fine, thank you. I sometimes turn to magit when I want to navigate a file's history through git-blame, though.

CLI is fine until you acquire a habit of committing things chunk-wise and line-wise. E.g., I have these 20 files modified, but I'll quickly skim through and add/commit the lines/chunks that are done, and then continue working on the rest. CLI promotes a different kind of workflow, like "ok, I'm done, add/commit it all, and then move on".

What do you feel the UI does better than git add -p? The main concession I have is picking arbitrary files, but I feel like I've achieved 90%+ of what I want with '.cs' or 'Controller*' etc.

Re: Oh shit, git (2016)

#139

Post by kyberias »

mehrdadn wrote: post #71
kyberias wrote: post #13

Earlier quoted context omitted.

I think you are right about the DAG. Once I understood what the high-level data structure of git is, many branch related commands immediately made sense and it was suddenly very easy to use. Many of my colleagues haven't taken the time to learn that and continuously struggle with basic commands.

Honestly the DAG isn't the whole story. The distributed nature also adds a twist that makes things entirely difficult, and the obtuseness of the commands is yet another layer of difficulty. People have every right to expect git commit to commit their changes to the remote repo. And it very well could, but it just doesn't happen to. Similarly you can't tell me with a straight face that notion of having to 'git add' a…

I agree it's not the end of the story, but without that knowledge, learning git is almost impossible. Even with DAG knowledge, some commands are hard to remember.

Re: Oh shit, git (2016)

#140

Post by mannykannot »

avar wrote: post #105
jchw wrote: post #35

Earlier quoted context omitted.

I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. That’s not all it has going for it either. Mercurial has a concept of commit stages to make history rewriting safer. It has a commit model that enables you to work on and manipulate branches of commits seamlessly, without needing named branches. It has not just a tree of commits but also each commit trac…

> Mercurial feels like it should be the winner. The commands are more uniform and predictable. Keith Packard's "Repository Formats Matter" post nicely captures how meaningless it is to focus on this sort of thing in the long term: https://keithp.com/blogs/Repository_Formats_Matter/ I.e. yes Git has some UI issues, but those are fixable, whereas e.g. Subversion's UI was way better than Git in the early days, but its r…

Your response to the first point appears to explain why Git largely replaced Subversion, but it is not clear that it applies to Mercurial.
Post reply on HN