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

101–110 of 200 posts

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

#101

Post by yCombLinks »

OkayPhysicist wrote: post #48

I'm not a fan of this mythos around Git's complexity. It is simply a DAG, a bunch of references to nodes in that graph, and a stack of commands that let you make any modification to that system you so desire. If you just learn the mapping of those concepts to Git's vocabulary, you really don't need to memorize all the commands. In the odd case, you can just look up the docs. Nodes are commits, references are either b…

A counterpoint: I have an entire department of non-tech users that need to sync and version control documents at work. Not one of them has ever had a problem with SVN pulling and pushing to handle this. Git is completely inaccessible to this group of people, as soon as I tell them it's just a Directed Acyclic Graph with a pointer to a node I rightfully deserved to be laughed out of the room

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

#102

Post by yCombLinks »

bombcar wrote: post #49
OkayPhysicist wrote: post #48

I'm not a fan of this mythos around Git's complexity. It is simply a DAG, a bunch of references to nodes in that graph, and a stack of commands that let you make any modification to that system you so desire. If you just learn the mapping of those concepts to Git's vocabulary, you really don't need to memorize all the commands. In the odd case, you can just look up the docs. Nodes are commits, references are either b…

There's a strong current in all tech things where "I couldn't figure it out intuitively the first time I sat down and tried it" becomes exactly the same as "this is ungodly complex and impossible to use". I've seen it leveled against emacs, git, vim, etc. It's kind of sad. I suspect that "attempts to explain something in an easy (but subtly wrong) way" have fueled it with regards to git.

The problem is I've used multiple version control systems before git that were far simpler to use day to day, and fulfilled all of my needs. Be sad man.

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

#103

Post by HWR_14 »

brianwawok wrote: post #98
HWR_14 wrote: post #67

Earlier quoted context omitted.

Am I the only one sad that Git beat out Mercurial as the industry standard? And am I also the only one who still knows how to do things in Mercurial but not how to take the corresponding action in Git? I mean, they're things I haven't had a reason to do in years, but it has some psychological cost to feel like I'm using a system I'm worse at.

I was on the team of a large org doing a POC between the two. Merc did some stuff better, git did more. I am glad git won out overall. I think the only feature Merc had that I cared about was tracking folders as objects.

Mind if I ask what Git did better? The main selling point for the difference between them was the Linus, Linux and then the whole community chose Git.

The only big difference I recall Git winning on was in third party tooling and Git supporting more than two parents merging.

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

#104

Post by [deleted] »

HWR_14 wrote: post #67
skrebbel wrote: post #7

Fwiw a branch isn't a named sequence of commits, it's just a label that points to a single commit. It's exactly the same as a tag except that git moves it when you make a new commit. Mercurial calls these bookmarks which IMO is a much better name because it works exactly like real bookmarks (in books, not browsers). A git branch feels a little bit like a branch of a tree because each commit points to their parent. Th…

Am I the only one sad that Git beat out Mercurial as the industry standard? And am I also the only one who still knows how to do things in Mercurial but not how to take the corresponding action in Git? I mean, they're things I haven't had a reason to do in years, but it has some psychological cost to feel like I'm using a system I'm worse at.

[deleted]

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

#105

Post by pjdkoch »

hbn wrote: post #18

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 incomin…

> 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

`git config --global merge.conflictStyle diff3`

If you ever wanna go back to the command line, your life will be much easier.

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

#106

Post by pdonis »

skrebbel wrote: post #7

Fwiw a branch isn't a named sequence of commits, it's just a label that points to a single commit. It's exactly the same as a tag except that git moves it when you make a new commit. Mercurial calls these bookmarks which IMO is a much better name because it works exactly like real bookmarks (in books, not browsers). A git branch feels a little bit like a branch of a tree because each commit points to their parent. Th…

> each commit points to their parent. Therefore, you don't need to track the entire sequence of commits in the branch but just the commit at the tip.

This is not entirely true, because it is perfectly possible to create commit graphs in git in which there is not a single well-defined branch for some commits. So just knowing the branch labels at each tip is not sufficient to assign a single well-defined branch to every commit in the graph.

Mercurial branches don't work like this: they are actually stored as part of each commit, so even with ambiguous commit graphs each commit still has a well-defined branch.

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

#107

Post by pierrebai »

mjd wrote: post #76
skrebbel wrote: post #64

Earlier quoted context omitted.

Sure but then why do they describe the term wrong in the first paragraph? That's just adding to the confusion they intend to fight. I'm not sure the author is reading this, but think it's worth rewording.

I'm reading it and I think I got it right. The Git community, the Git documentation, and the Git tools all refer to "branches", and I think what they mean when they talk about "branches" is much closer to what I described than to what you did. For example, consider this very ordinary-sounding phrase that I just picked out of the git-rebase man page: > If the upstream branch already contains a change you have made … I…

The problem is that your rebuttal isn't one: you are not addressing any of the points made. And those points are important precisely because branches are not a range of commits which is why they are cumbersome to work with.

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

#108

Post by pierrebai »

intrepidhero wrote: post #12

> 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 situati…

> My second question is, if the underlying model is so f*cking elegant, how did it lead to such a confusing interface?

This is the consequence of elegance. Elegance at one level usually is characterized by being very data-agnostic, very workflow-agnostic, etc. This leads to anything built on top of it to be so generic its unusable or at least very awkward.

Pretty much everyone who works with git daily has a set of script to do the actual day-to-day work. The git command is too awful to use otherwise.

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

#109

Post by toyg »

HWR_14 wrote: post #103
brianwawok wrote: post #98

Earlier quoted context omitted.

I was on the team of a large org doing a POC between the two. Merc did some stuff better, git did more. I am glad git won out overall. I think the only feature Merc had that I cared about was tracking folders as objects.

Mind if I ask what Git did better? The main selling point for the difference between them was the Linus, Linux and then the whole community chose Git. The only big difference I recall Git winning on was in third party tooling and Git supporting more than two parents merging.

Git wasn't really winning until GitHub emerged. The game was still open at that point. Once GH had resoundingly beat the competition for "social coding" (like bitbucket and sourceforge), though, it was all over.

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

#110

Post by [deleted] »

mjd wrote: post #76
skrebbel wrote: post #64

Earlier quoted context omitted.

Sure but then why do they describe the term wrong in the first paragraph? That's just adding to the confusion they intend to fight. I'm not sure the author is reading this, but think it's worth rewording.

I'm reading it and I think I got it right. The Git community, the Git documentation, and the Git tools all refer to "branches", and I think what they mean when they talk about "branches" is much closer to what I described than to what you did. For example, consider this very ordinary-sounding phrase that I just picked out of the git-rebase man page: > If the upstream branch already contains a change you have made … I…

[deleted]
Post reply on HN