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

131–140 of 200 posts

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

#131

Post by georgia_peach »

cryptonector wrote: post #79
georgia_peach wrote: post #19

The thing I wish everyone knew about Git is that Mercurial is better. Much much better. https://hginit.github.io/

Which is ironically hosted on a Git (GH) repo. Mercurial is dead.

Mercurial @ Facebook & Mozilla, per Wikipedia:

> Although Mercurial was not selected to manage the Linux kernel sources, it has been adopted by several organizations, including Facebook, the W3C, and Mozilla. Facebook is using the Rust programming language to write Mononoke, a Mercurial server specifically designed to support large multi-project repositories.

Mercurial @ Google:

> Speaking of Google, their Mercurial rollout on the massive Google monorepo continues. Apparently their users are very pleased with Mercurial - so much so that they initially thought their user sentiment numbers were wrong because they were so high! Google's contribution approach with Mercurial is to upstream as many of their modifications and custom extensions as possible: they seem to want to run a vanilla Mercurial out-of-the-box as possible. Their feature contributions so far have been very well received upstream and they've been contributing a number of performance improvements as well. Their contributions should translate to a better Mercurial experience for all.

https://groups.google.com/g/mozilla.dev.version-control/c/hh...

GitHub is a fine place to stash free code for free. Adding Linus Torvalds' good name to "free storage" is an unbeatable combination for mindshare, but does not change the fact that mercurial is far more ergonomic for the typical cases, and handles facebook/google scale well enough.

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

#133

Post by chx »

stu2b50 wrote: post #71
chx wrote: post #30

> When I first used Git it drove me almost to tears of rage and frustration. But I did get it under control. I don't love Git, but I use it every day, by choice, and I use it effectively. Yes. For me the rescue was Charles Duan's git tutorial: Understanding Git conceptually. https://www.sbf5.com/~cduan/technical/git/ > you can only really use Git if you understand how Git works. Merely memorizing which commands you s…

> I disagree. Anything that ends up in a commit should be recoverable (on the same local git repository, that is), no? The main things that can forever clobber your work afaik is git checkout -- , which will perhaps a little unintuitively just clobber over whatever is not committed.

the big killer in my experience is git reset --hard which is what the script protects against.

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

#134

Post by wolfgang42 »

kjeetgill wrote: post #120
mikewarot wrote: post #92

It was only recently that I learned GIT doesn't store deltas as it's core functionality, which is how I had presumed it works. It's just saving snapshots, and making up the deltas in retrospect, for purposes of merging, etc. In using it, you're always confronted with deltas, so it seemed that was how it worked. The command structure didn't correspond at all, and was thus very confusing. Git is really a contents addre…

> Git is really a contents addressable archive disguised as a version tracking system. This is a great take. I think I got lucky that I went from "copying whole directories to save my work before a refractor" directly to git without leaning svn or anything else first. Treating it as a snapshot management/copy-on-write content addressable storage + diffing utilities is a perfect way of thinking about it. I always wish…

Yeah, this is how I always introduce git to newbies. “You know how you zip up a copy of your project when you have a version you want to keep? Git is that, except with a bunch of (sometimes slightly wonky) tools to keep track of everything.”

I also try to start them off with gitk/`git gui`, which make it a lot easier to understand what’s going on (“ok, so here you see a diff with the changes you made. Now you stage the file, and it moves down here. You can put it back by unstaging it, but for the moment let’s commit it. Now in the graph you can see your new commit, with a line pointing at the parent, and your branch pointer moved along with it, but the origin/branch pointer stayed behind, so to get that to move we need to push the new commit to the remote...”)

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

#135

Post by layer8 »

smusamashah wrote: post #95
layer8 wrote: post #94

Earlier quoted context omitted.

That’s the easy part. It doesn’t tell you how local and remote interact and how the working tree, index and repository interact, and how to handle the issues you can run into with merging, rebasing, etc.

Rebasing is when a whole branch (a chain of commits) is picked up and moved on to some other commit. It's easy to build up on that. Working tree is current state of files. Index is the staging area or the buffer (if I am not forgetting) where you put your changes you are about to permanently commit. Git is distributed system. Your repo can point to another repo as its remote copy. Can have multiple remotes. The defau…

I’m not talking about understanding what a rebase is supposed to achieve, I’m talking about the merge conflicts than can arise while rebasing, understanding why they happen and how to deal with them.

I’m not talking about understanding what the working tree and index are, but how they interact under the various commands, what happens with the working tree and index state for example when you switch a branch, etc.

I’m not talking about a basic understanding of what a remote is, but about how to deal with different remotes, how to have local branches, how to push/pull only some branches vs. all branches, and so on.

Those are the things where people get in trouble and into broken states.

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

#136

Post by layer8 »

mjd wrote: post #100
layer8 wrote: post #87

Earlier quoted context omitted.

But what’s the precise rule defining what constitutes the commits of a branch, after you reach a merge point? Does the branch end there? If not, which parent of the merge does it go? It’s not clear a priori.

I don't think there is a precise rule. because the exact meaning depends on the context. In part 3 of the series, in the section about "branches are fictitious", that's what I will say. The talk has an abbreviated version: https://perl.plover.com/classes/git-tips/samples/slide018.ht... It's an illustration of just one example of this: If we rebase "branch X" onto commit B, we rebase only the three green commits. But…

Right, and that’s what makes “branch” a vague notion in git. It’s not clear what exactly is meant with “branch x” when it’s not just about the labeled tip, and often enough no further clarification is given.

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

#138

Post by emmelaich »

kjeetgill wrote: post #114
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…

I think bookmarks are a fine name but I don't really see quibble about branches, which I think are an even better name, but I know it's because I'm seeing it with my git goggles on. Can you elaborate on what you think branches are a better reference to? What operations or concepts are better expressed in terms of them? I think I'm at the edge of an epiphany here ... but I'm not quite groking it yet.

The issue is the "named" bit of the definition, more precisely "named sequence".

A commit is as much a branch as a head of a linked list is both a node and a list.

I think 'branch' is fine.

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

#139

Post by emmelaich »

mikewarot wrote: post #92

It was only recently that I learned GIT doesn't store deltas as it's core functionality, which is how I had presumed it works. It's just saving snapshots, and making up the deltas in retrospect, for purposes of merging, etc. In using it, you're always confronted with deltas, so it seemed that was how it worked. The command structure didn't correspond at all, and was thus very confusing. Git is really a contents addre…

This is in fact how Linus has described it. A content-addressable user-level filesystem. Or words like that.

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

#140

Post by cryptonector »

kjeetgill wrote: post #124
cryptonector wrote: post #78

Earlier quoted context omitted.

Basically, making `git reset --hard` and `git checkout -f` auto-stash would be great.

If I had to pick my version of this solution to fix 60% of git's learning curve problems: a) Don't tell people about stash. All Commits Everything. b) All commands that change the working directory or branches should fail on uncommitted work and ask you to git commit. It already does this for untracked changes. c) Show people show git branch BACKUP (requiring a commit) + git reset --hard BACKUP will always get you ba…

Yes. Plus commands that alter dirty workspace files could just do a "stash" like thing.
Post reply on HN