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

61–70 of 200 posts

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

#61

Post by jcranmer »

radarsat1 wrote: post #52
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…

> Why hasn't someone written new porcelain that makes git as intuitive as mercurial, subversion, etc? I've used svn and git extensively, but after getting very used to git, i tried working on a project that used mercurial and walked away completely confused by how it works. With "branches" being completely different beasts that i couldn't understand and unsure when it was appropriate to use bookmarks instead. It comp…

If you're coming from git, this is what you need to do to understand Mercurial: don't worry about Mercurial's branches, ever. Whenever you want to use the term 'branch' from git, translate it to 'bookmark'. Mercurial's branches correspond more directly to svn's branches--they're immutable properties of a revision--but it's not a terribly useful property, and you can forget about them entirely and be perfectly productive.

Although note that unlike git, you don't need to use Mercurial's bookmarks since Mercurial is perfectly happen to let commits sit around without having names pointing to them.

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

#62

Post by digisign »

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…

Sounds great. But doesn't get anyone from point A to point B.

It's like being handed city maps of LA and NYC and told to drive from one to the other.

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

#63

Post by eropple »

dotancohen wrote: post #51
amcoy37 wrote: post #29

Earlier quoted context omitted.

Accidentally running a git command in the wrong folder is pretty easy to do at the command line. I was, at one point, in the habbit of running "git checkout ." after writing some experimental code. Several times a day, or however often. So of course, I once accidentally ran that command in the wrong repo and obliterated some pending changes that hadn't been commited.

How is that git's fault? I used to `vim test.c` then `rm Alt-.` very very often. Until one day sure enough I'm in the wrong directory, and I actually saw `Alt-.` complete the filename of an important file, but the brain veto latency is slower than the muscle memory twitch and my pinky continued on over to the Enter key. I blame only Dotan and changed my work habits. Bash had nothing to do with the incident.

I dunno - I can tell zsh to are-you-sure me about an `rm -rf *`, git seems like it should be able to do similarly. Or, as Mercurial does, back up overwritten files to .bak.

These are pretty light asks.

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

#64

Post by skrebbel »

jsmith45 wrote: post #35
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…

This is exactly the point the author plans to address under "Branches are fictitious", in the outline at the top.

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.

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

#65

Post by krono »

The Git docs are very comprehensive and the writing is surprisingly easy to follow.

Also you're totally allowed to set up private repos and run whatever dodgy commands some karma-poor guy on SO claims should sort you out and see what you end up with, or create a "rewritten history" scenario that everyone has always been warning you to avoid (forbidden fruit...).

In summary: Read the docs and git grokking!

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

#66

Post by ziml77 »

WanderPanda wrote: post #36
kortex wrote: post #26

Earlier quoted context omitted.

> My question is why hasn't anyone come along and fixed it? There's been dozens of "replacements"/frontends/guis for git, off the top of my head: gitless, magit, tortoise git, gitkraken. Heres a whole mess of em: https://git.wiki.kernel.org/index.php/Interfaces,_frontends,... > My second question is, if the underlying model is so f*cking elegant, how did it lead to such a confusing interface? I think this is 66% beca…

I believe I will never figure out when I have to use "remove" "delete" "-d". These naming inconsistencies make it a lot harder than necessary

A porcelain whose only purpose is to address those inconsistencies would be wonderful.

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

#67

Post by HWR_14 »

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.

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

#68

Post by HWR_14 »

hinkley wrote: post #55
Anunayj wrote: post #31

Earlier quoted context omitted.

and Just for fun, sometimes it can be as big as 66, meet Cthulhu merge [1] 1. https://lkml.org/lkml/2014/1/21/361

Linus doesn't appear to be particularly enthusiastic about this strategy. Humans really do handle treating changes as a sequence. I wonder if this was really necessary or could have been serialized.

Mercurial, by the spec, only allows two parents to force merges like that into a sequence.

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

#69

Post by chronometry888 »

compiler-guy wrote: post #46
atq2119 wrote: post #24

Earlier quoted context omitted.

> Unfortunately, this is not quite true. Git checkout will silently and irretrievably clobber all the changes in your working tree. Not by default it won't. It can do that, if you explicitly run it with the options to checkout a specific path. But why would you do that if it's not what you want?

"Just don't make a mistake" is a pretty bad strategy.

But "save your changes before running a command that can clobber" is a pretty good strategy.
Post reply on HN