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

91–100 of 200 posts

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

#91

Post by edflsafoiewq »

layer8 wrote: post #87
mjd wrote: post #76

Earlier quoted context omitted.

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…

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 think it goes to all the parents, ie. a branch denote not a linear sequence of commits, but an entire sub-DAG.

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

#92

Post by mikewarot »

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 addressable archive disguised as a version tracking system.

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

#94

Post by layer8 »

smusamashah wrote: post #50

If you can understand the data structure git uses (Merkel Trees) it becomes easy to understand git (won't help with the CLI though). I think it can be summarized as Linked List in reverse. New entries are always added on head instead of tail. The pointer used to track the growing list is 'branch' pointer. The pointer that is fixed to a specific node is 'tag'. Since we are adding on Head, we can have multiple nodes po…

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.

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

#95

Post by smusamashah »

layer8 wrote: post #94
smusamashah wrote: post #50

If you can understand the data structure git uses (Merkel Trees) it becomes easy to understand git (won't help with the CLI though). I think it can be summarized as Linked List in reverse. New entries are always added on head instead of tail. The pointer used to track the growing list is 'branch' pointer. The pointer that is fixed to a specific node is 'tag'. Since we are adding on Head, we can have multiple nodes po…

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 default remote is 'origin'. When pushed, changes are uploaded to that remote repo. The remote repo doesn't have to be on a server. You can have it locally in another folder. When you push, your changes will be copied to that one too.

Edit: I don't know how merge really works, and merge issues have been difficult to resolve therefore.

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

#96

Post by lisper »

cryptonector wrote: post #75
lisper wrote: post #11

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

Never `git checkout -f` or `git reset --hard` unless you know you want to throw away extant changes from the workspace. That's it. Know that, live that, and you'll never lose work because of Git.

Nope. There is at least one other case that loses work irretrievably. Details can be found in sibling comments.

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

#97

Post by yCombLinks »

cryptonector wrote: post #74
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 question is why hasn't anyone come along and fixed it? Because the model is simple and easy to understand, and you get a lot of power from understanding it. Whereas opinionated porcelain that tries to insulate the user from the model will tend to fail in obnoxious ways and will not serve the user. Really, there's objects, there's commits, then there's a couple of methods for symbolically naming commits (branches…

The problem isn't requiring knowledge of the model, the problem is inconsistencies in the git commands for working with the model.

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

#98

Post by brianwawok »

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.

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.

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

#99

Post by corytheboyd »

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 resolver is really so fantastic, miles better than other visual merge tools I've used.

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

#100

Post by mjd »

layer8 wrote: post #87
mjd wrote: post #76

Earlier quoted context omitted.

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…

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 if we rebase it onto C, we consider X to contain the two dark blue commits also.

Are the dark blue commits part of branch X? It depends on what you're trying to communicate.

Post reply on HN