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

Oh Shit, Git

ohshitgit.com

Post reply on HN
Print view View original

181–190 of 237 posts

Re: Oh Shit, Git

#181

Post by Nullabillity »

canaus wrote: post #151
dahart wrote: post #131

Earlier quoted context omitted.

> I find people are religious about being git cli purists […] we have state of the art GUI tools I would humbly suggest you avoid framing it that way, even if you believe it’s true. From someone who is only sometimes a cli advocate, my immediate assumption is that your opinion here may be formed out of naïveté and a bit of fear of the cli. Please note I’m actually quite a fan of using various GUI tools for basic git…

I'd really like to know what mess people make when they don't rebase. I've found that using merge gives a readable trail of when something was merged, whether that be from a branch's original branch, or if you're merging into another branch. Rebasing just seems to cause a lot more headache when something doesn't go perfectly correct in between commits.

> I'd really like to know what mess people make when they don't rebase.

I think this part is really telling:

> And worth mentioning, the question’s partially moot for people using Github or other hosting services where some GUI tools are built-in. Using the CLI for all interactions with Github, and using the site for the visualizing diffs & branches is totally reasonable.

GitHub's branch view is uniquely awful, and doesn't try to call out branch history at all. Commit lists should either include a railroad diagram or only include the left-facing history. Anything else is just inexcusably broken.

Re: Oh Shit, Git

#182

Post by carso »

sircastor wrote: post #134
gpspake wrote: post #108

I find people are religious about being git cli purists and only interacting with it in this black box (the terminal). On top of that a lot of people stop learning git after add commit push pull branch and merge so concepts like rebasing and cherry picking are scary. In this day and age we have state of the art GUI tools that change the game and allow git users to see and interact with the state of a git repository i…

I think the thing that’s at the root of most git issues is the lack of atomic commits. Most people I know commit at the “block of work” or “ticket” level. Once they have the thing they wanted done, they commit. It means that fundamentally they can’t cherry pick, and rebasing occurs on huge blocks of code instead of single lines. It’s not there yet, but I kind of think git should be used the way I started using the sa…

Funny. The way I found to not get yelled at for having too many commits is to just “git commit —amend” every time I want to checkpoint and only push when the ticket is done.

Git has an extraordinary collection of foot guns and unwritten rules. I’ve been using it three years and often feel like I just get by (and also the devs who came up with the conventions in my org maybe could have chosen better)?

Re: Oh Shit, Git

#183

Post by Nullabillity »

metaltyphoon wrote: post #164
canaus wrote: post #151

Earlier quoted context omitted.

I'd really like to know what mess people make when they don't rebase. I've found that using merge gives a readable trail of when something was merged, whether that be from a branch's original branch, or if you're merging into another branch. Rebasing just seems to cause a lot more headache when something doesn't go perfectly correct in between commits.

Interesting take. If anyone care to actually learn how git works when rebasing, then it becomes much simpler. I always rebase and in 10 years of professional use, never once had a problem with it. That doesn’t mean other people don’t.

But you're still going to have a worse history than you would have by just letting git merge Do The Right Thing.

Re: Oh Shit, Git

#184

Post by lemmsjid »

xwdv wrote: post #136
gpspake wrote: post #108

I find people are religious about being git cli purists and only interacting with it in this black box (the terminal). On top of that a lot of people stop learning git after add commit push pull branch and merge so concepts like rebasing and cherry picking are scary. In this day and age we have state of the art GUI tools that change the game and allow git users to see and interact with the state of a git repository i…

Quoted post unavailable.

I’m trying to write a helpful reply instead of downvoting. If you use those kind of criteria to determine someone’s knowledge, you’re going to come across as dogmatic, reductionist, etc. I doubt you are really that way, but it’s how it comes across, and it doesn’t make for good discussion. I’d suggest laying out why you think someone’s preference for a gui means they know nothing.

Re: Oh Shit, Git

#185

Post by KronisLV »

canaus wrote: post #151
dahart wrote: post #131

Earlier quoted context omitted.

> I find people are religious about being git cli purists […] we have state of the art GUI tools I would humbly suggest you avoid framing it that way, even if you believe it’s true. From someone who is only sometimes a cli advocate, my immediate assumption is that your opinion here may be formed out of naïveté and a bit of fear of the cli. Please note I’m actually quite a fan of using various GUI tools for basic git…

I'd really like to know what mess people make when they don't rebase. I've found that using merge gives a readable trail of when something was merged, whether that be from a branch's original branch, or if you're merging into another branch. Rebasing just seems to cause a lot more headache when something doesn't go perfectly correct in between commits.

> I'd really like to know what mess people make when they don't rebase.

I work on a project that has been around for ~8 years and there have always been ~5-10 people working at the same time on the codebase.

Nobody rebases, nor do they squash branches on merges into the branches. It's about as good as you'd imagine.

Re: Oh Shit, Git

#186

Post by elsjaako »

zoomablemind wrote: post #160
motoboi wrote: post #156

> # remove the last commit from the master branch > git reset HEAD~ --hard I see this all the time, this "commits ON a branch" mentality. My secret to understanding git is: branches are just adresses, labels, pointers, aliases to commits. A branch is just a label pointing to a commit. So, you don't "remove (or add) a commit from a branch", you change where a branch point to. Commits are tree nodes, they have a parent…

>...So, you don't "remove (or add) a commit from a branch", you change where a branch point to. Well, once committed, the corresponding deltas to parent are part of the branch (that is a node of the branch graph). Thus, if user wants to have this commit in a different graph, then the deltas need to be regenerated and recommitted (then deleted from the wrong graph). As for the branch name , in Git it's just a label fo…

If you are talking about the thing that git calls a branch, it's literally just a pointer to a commit. You can look it up manually. Here is a random repo I have on my PC:

  ~/p/s/sigrok-cli> cat .git/refs/heads/master
  7bdc46d6fcdcfa00dd29ac102f3128aeb44a479c
In principle all these objects are in the .git/objects folder. But the encoding is some binary thing for branches, and anyway it's often stored differently (I assume for space saving reasons). But git can explain what every object is.

  ~/p/s/sigrok-cli> git cat-file -p 7bdc46d6fcdcfa00dd29ac102f3128aeb44a479c
  tree fa02da4030e5791695b8a7a5400ee2c2cc88ee46
  parent 09fc39da486b8618d65b66ca96a760478c3e89e2
  author Uwe Hermann  1454100673 +0100
  committer Uwe Hermann  1454100673 +0100
  
  NEWS: Update for upcoming 0.6.0 release.
  ~/p/s/sigrok-cli> git cat-file -p fa02da4030e5791695b8a7a5400ee2c2cc88ee46
  100644 blob d1d8ffca429d2a4697a56fd7dedbeee3fc6d577d    .gitignore
  100644 blob 28c1b20e6d7d146fbc6ad0270ff5b09cfd057b26    AUTHORS
  100644 blob 94a9ed024d3859793618152ea559a168bbcbb5e2    COPYING
  100644 blob 04c29abe3dc42c8ecb8ec1b71093437d8c382ebd    HACKING
  100644 blob c6d6c8a7cff1a5b7d940e0c040ad1d4f5337f646    Makefile.am
  ... etc
The git software just updates the branch to create the illusion that it's not just a pointer to a commit. But really, it's literally a file with the sha1 hash of the commit.

Re: Oh Shit, Git

#187

Post by Dylan16807 »

zoomablemind wrote: post #160
motoboi wrote: post #156

> # remove the last commit from the master branch > git reset HEAD~ --hard I see this all the time, this "commits ON a branch" mentality. My secret to understanding git is: branches are just adresses, labels, pointers, aliases to commits. A branch is just a label pointing to a commit. So, you don't "remove (or add) a commit from a branch", you change where a branch point to. Commits are tree nodes, they have a parent…

>...So, you don't "remove (or add) a commit from a branch", you change where a branch point to. Well, once committed, the corresponding deltas to parent are part of the branch (that is a node of the branch graph). Thus, if user wants to have this commit in a different graph, then the deltas need to be regenerated and recommitted (then deleted from the wrong graph). As for the branch name , in Git it's just a label fo…

What deltas? Commits are full snapshots.

The only time deltas come into play are in pack files, and those store objects in completely arbitrary order.

Re: Oh Shit, Git

#188

Post by at_a_remove »

nocman wrote: post #168
at_a_remove wrote: post #152

My first introduction to git was ... well, the professor's solution to not having a place to upload. Given that the vast majority of the students involved had done almost no programming before, it didn't go so hot. I managed. My first "production" introduction to git was really about someone polishing their resume and chanting magic words at me. Merges ... happen? Who decides whether Bob or Cindy's code is used here?…

> How is "reflog" the correct and intuitive choice for "undo"? Was there something I wasn't understanding? No, I'm just supposed to accept that. Actually your initial intuition was correct. There are things you obviously don't understand about git. "reflog" is short for reference log. As "git help reflog" will tell you: Reference logs, or "reflogs", record when the tips of branches and other references were updated i…

You have made my point for me. "This command manages the information recorded in the reflogs." WHAT?

Of course everything has an obvious name if you have to learn everything about it. The point I am making is that the name ought to be obvious before you have to learn everything about it. "Undo" is a reasonable choice if you barely understand what git is for and "reflog" is not. Once you master a system and agree to all of its axioms and warts, it's all logical from the inside. That's true of almost any system, though.

Re: Oh Shit, Git

#189

Post by stjohnswarts »

bhrgunatha wrote: post #36
somewhereoutth wrote: post #15

My mental model of a git repo is basically a bramble bush with labels on it. The bramble stems and branches are the commit history (which may join and well as split, unlike a bramble). The labels are stuck to particular bits of the bramble. Some labels are even stuck to other labels! You can move the labels around, and you can glue extra bits of bramble to the tips of what you have. You can even hack about with the b…

Learning the underlying model behind git is well worth the effort. For me watching Steve Smith's talk - Knowledge is Power: Getting out of Trouble by Understanding Git - was a lightbulb moment. Here's a 2019 presentation of that talk. https://www.youtube.com/watch?v=fHLcZGi3yMQ

thanks, I'll be watching this. seems like I get myself in trouble every couple of months and have to zip up a directory, do a fresh checkout and overlay it. Seems sometimes something gets lost and it will refuse to push to origin on a branch that I've had checked out for a while. yet if I do a fresh checkout (and losing a bit of history as I like to commit locally a lot and squash just before I'm ready to push to git repo.

Re: Oh Shit, Git

#190

Post by dahart »

Nullabillity wrote: post #183
metaltyphoon wrote: post #164

Earlier quoted context omitted.

Interesting take. If anyone care to actually learn how git works when rebasing, then it becomes much simpler. I always rebase and in 10 years of professional use, never once had a problem with it. That doesn’t mean other people don’t.

But you're still going to have a worse history than you would have by just letting git merge Do The Right Thing.

Naw, merge is orthogonal to cleaning up local history. Merging a mess is still a mess. Some people are fairly clean from the start, and some aren’t. And it depends on the task at hand, messes are easier to make when you’re doing more than one thing at a time.
Post reply on HN