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

Ask HN: What made you finally grok Git?

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 94 posts

Re: Ask HN: What made you finally grok Git?

#41

Post by globular-toast »

doix wrote: post #5

When I realized it's just a DAG and you're just manipulating a graph and pointers. Then it just became a matter of mapping git CLI commands to how they manipulate the graph.

But note that git's data store (the bit where actual code/content is kept) is fundamentally append only. You can't manipulate anything there. You can only add different versions. The only pointers you can actually change are branches and HEAD. This is really, really important to understanding git and actually trusting it to keep your work safe.

Re: Ask HN: What made you finally grok Git?

#42

Post by xwowsersx »

chrisshroba wrote: post #10
mcv wrote: post #8

What's important to understand about git is that it allows time travel, and time travel enables changing history, and changing history is a really bad idea. Do not ever change the history without knowing what you're doing. In git, this means mostly rebasing and other stuff that messes with existing commits. Messing with existing commits can be fine as long as you're messing with the only existing version of that comm…

I just ran into this problem last night... if you shouldn't rebase after pushing to remote, how do you update a PR days after you originally created it to be on top of the latest origin/master and be able to resolve merge conflicts locally?

No, you only shouldn't rebase if you pushed to a shared branch. If it's your PR that only you are working on and you need to update it to the latest in the master branch, rebasing is the correct way to do this. There isn't a magical rule about not pushing to a remote branch. The point is to recognize that rebasing rewrites the history which is a problem if and only if that history has already been relied on by someone else or otherwise integrated in such a way that rewriting that history is destructive. If it's your PR, then as far as anyone else is concerned, you DID just checkout the latest from master and branch off of it. No one needs to know or care that you actually rebased.

Re: Ask HN: What made you finally grok Git?

#43

Post by beaker52 »

paulgb wrote: post #20
doix wrote: post #17

Earlier quoted context omitted.

My bad, stands for directed (not acrylic) acyclic graph, which is just a fancy way saying a graph with no loops. Edit: yeah, it's acyclic not acrylic :).

acyclic, not acrylic ;)

Bob Ross enters the chat

Re: Ask HN: What made you finally grok Git?

#44

Post by AndrewDucker »

worldsayshi wrote: post #25
doix wrote: post #5

When I realized it's just a DAG and you're just manipulating a graph and pointers. Then it just became a matter of mapping git CLI commands to how they manipulate the graph.

I still don't fully understand what the nodes and edges in this graph "is" though. It's not patches. And I can't believe it is "all of the code" in each commit because that sounds very expensive.

It's not 'all the code', it's the directory info, and links to every file, the vast majority of both of which will already be in the repo.

Re: Ask HN: What made you finally grok Git?

#45

Post by criley2 »

chrisshroba wrote: post #10
mcv wrote: post #8

What's important to understand about git is that it allows time travel, and time travel enables changing history, and changing history is a really bad idea. Do not ever change the history without knowing what you're doing. In git, this means mostly rebasing and other stuff that messes with existing commits. Messing with existing commits can be fine as long as you're messing with the only existing version of that comm…

I just ran into this problem last night... if you shouldn't rebase after pushing to remote, how do you update a PR days after you originally created it to be on top of the latest origin/master and be able to resolve merge conflicts locally?

You don't rebase it ontop of main after you've published it because that will mean anyone else who has checked it out will have to like checkout -f to clean it up.

You just merge main in. Don't worry about extra commits that appear. PR tools like Github won't make people review them if you've done it all right, they can tell what a Merge Commit looks like (don't go deleting the auto-generated messages for merge commits unless you know what you're doing).

Once you merge main into your out-of-date branch, it'll be up to date. And when you merge your branch back into main after the PR, it will work out. This is the standard way you would work on a branch with a coworker, instead of working alone.

There's nothing wrong with merging main in.

If you absolutely MUST have a perfect history of your commits on top of THE CURRENT state of main, start a new branch, start a new PR, IMO. Just don't change public history.

Re: Ask HN: What made you finally grok Git?

#46

Post by doix »

chrisshroba wrote: post #10
mcv wrote: post #8

What's important to understand about git is that it allows time travel, and time travel enables changing history, and changing history is a really bad idea. Do not ever change the history without knowing what you're doing. In git, this means mostly rebasing and other stuff that messes with existing commits. Messing with existing commits can be fine as long as you're messing with the only existing version of that comm…

I just ran into this problem last night... if you shouldn't rebase after pushing to remote, how do you update a PR days after you originally created it to be on top of the latest origin/master and be able to resolve merge conflicts locally?

You can merge with master instead of rebasing, the downside is you'll end up with a lot of merge commits in a long living branch.

I just rebase and force push. I really don't get all the people that say avoid doing that. If you're the only one working on that branch, there's no risk.

If you're working with other people on the branch, and no one has unpushed changes, it's also fine. Everyone will just need to reset to the origin version of the branch to keep working.

If people do have unpushed changes and you force push, then they need to spend some time untangling it. Which is annoying, but it's not the end of the world. I don't get all the fear about it.

Don't rebase and force push master, that'll piss everyone off, sure. But doing it in branches is fine in most cases.

Re: Ask HN: What made you finally grok Git?

#47

Post by orzig »

Make a sandbox repository and just break it repeatedly. Within the realm of basic commands, I bet you already know how to do most things (including recovering from small mistakes), but it feels too scary so you revert to non-– GIT methods. In a sandbox, you can get the reps in without any fear.

You could then graduate to forking a real repo. Again experiment fearlessly, with slightly more realistic scenarios.

Re: Ask HN: What made you finally grok Git?

#49

Post by djtango »

worldsayshi wrote: post #25
doix wrote: post #5

When I realized it's just a DAG and you're just manipulating a graph and pointers. Then it just became a matter of mapping git CLI commands to how they manipulate the graph.

I still don't fully understand what the nodes and edges in this graph "is" though. It's not patches. And I can't believe it is "all of the code" in each commit because that sounds very expensive.

My mental model is each edge is a diff and each node is the aggregate of all edges + the starting state

Re: Ask HN: What made you finally grok Git?

#50

Post by chrismorgan »

he_is_legend wrote: post #29

The trick(s) to git is not using `git add -A`, and being diligent (as in checking before you commit) about the changes that you are committing. Only add and commit what is relevant to the task that you are working on. But it's even simpler than that. Before you commit anything, check what you are about to commit. Is it what you expected? Is it relevant? Does it work? Has it been tested? Is it likely to pass a code re…

> Before you commit anything, check what you are about to commit.

Better still, check it as you commit, by enabling the config option commit.verbose (e.g. `git config --global commit.verbose 1`), so that the full patch that is to be committed is shown in COMMIT_EDITMSG, not just the file names that you touched. This removes the race condition between review and commit.

(While on this topic, I also recommend commit.cleanup = scissors, and reading through `git config --help`, or at least skimming it for basic familiarity with what options are available to you. A few more that I like: merge.conflictStyle = diff3, diff.algorithm = histogram, mergetool.keepBackup = false.)

Post reply on HN