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

Idiot Proof Git

softwaredoug.com

Post reply on HN
Print view View original

151–160 of 435 posts

Re: Idiot Proof Git

#151

Post by Shacklz »

daneel_w wrote: post #16

I'm incredibly thankful that 99% of my Git usage at work gets away with just PULL, CHECKOUT [-b], COMMIT [--amend] and PUSH. Rarely do I need to rebase, for any reason.

I understand the sentiment, but since git is probably one of the longer-lasting constants in our industry (if not the longest-lasting constant), I personally think it's really worth to have a bit of a look into it.

Something I wish someone suggested to me years ago: Instead of trying to understand the commands, try to understand the datamodel. A branch is just a pointer to a commit, a commit is just a pointer (with metadata) to a tree, a tree is just... and so on. Once you understood this (which really isn't any harder than, say, understanding how quick-sort works), going from the data-model to the commands is fairly easy, almost intuitive if it weren't for all the convoluted options that each command can take.

Anyway, not trying to convince you or anything, just saying that I've been in your place a few years back, and wish I'd realized earlier how easy it actually is.

Re: Idiot Proof Git

#152

Post by twobitshifter »

derefr wrote: post #97
andrewvc wrote: post #31

Rebase should never be used. Or, if it is used, it should be treated as a dangerous thing to do that’s well outside the norm. Most of the arguments in favor of rebase are by people fanatical about having a git history organized just so. It’s not worth the headache and effort. PRs are a better unit of work than commits in practice. Configure GitHub or whatever you use to squash merge only and you’ll be good. Since mov…

So you're the one making me code-review 10000-line PRs because you just dumped your WIP branch — with three PRs' worth of code, plus formatting changes — directly into a PR, rather than factoring apart said WIP branch either during or after the fact. The designed unit of a (distributed) git workflow is a patch — i.e. a locally rebase-squashed set of cherry-picked commits from development branches, with `git reset --s…

Nobody should have long running WIP branches with these massive commits full of unrelated stuff. That’s an antipattern.

Re: Idiot Proof Git

#153

Post by planede »

softwaredoug wrote: post #49
alexb_ wrote: post #48

What's the deal with squashing commits anyways? I'm genuinely asking, because I've only worked with "squash everything before you put it up for review" but have never really figured out why past "it's what we've always done".

I think people will have a branch with like 40 dumb commits like "fix typo" but when you merge it, people don't want to go through all those 40 commits in main. They want to instead read "Refactored frob reactor to use glom framework".

merge commit with git log --first-parent is alright.

Re: Idiot Proof Git

#154

Post by evandale »

Izkata wrote: post #128
evandale wrote: post #122

Earlier quoted context omitted.

In my experience the squashing crowd is much louder and cares more about squashing than the crowd who prefers to see every commit. I hate squashing, but I've been beaten down into doing it many times because in the end it doesn't actually matter. The merge commits everywhere argument falls apart if you use log --no-merges. The shitty commit messages argument is solved by not allowing shitty commit messages. The "fixe…

> I hate squashing, but I've been beaten down into doing it many times because in the end it doesn't actually matter. For those of us on maintenance teams, who actually have to dig in to the history to figure out what happened, not squashing matters a lot .

You'll have to elaborate with specifics because in my experience it doesn't matter if there's 100 or 10000 commits - git bisect works great in both instances.

Re: Idiot Proof Git

#155

Post by cnity »

danwee wrote: post #130

Git commit crafting (and rebase to achieve it) is overrated. If you care about crafting beautiful series of commits so that the future readers understands what's going on: don't. Context is more useful to find out why something changed. Example: - you build feature F that is touching N files and M lines of code - you craft your git commits so that each of them is atomic and "understandable" on its own - now if I want…

> commit crafting is overrated.

For you, in your use case. When I look at my neat history and use git bisect, I get plenty of value out of it.

People keep telling me to stop rebasing. I keep ignoring them; nothing new here.

Re: Idiot Proof Git

#156

Post by aulin »

lelandfe wrote: post #144
stnmtn wrote: post #138

Earlier quoted context omitted.

Agreed. The first and last place I look at when doing a git blame is the PR that the commit was in. That contains all the useful information for me, as well as much-needed context around review comments, discussion, etc that is not able to find in native git.

Pull requests vanish when repos change hands. If you leave unique information in PRs, that information may be lost in the future. This has happened to me at 3 different companies now, where we inherited another company's code base. Keeping commits self-contained is the only way to future proof your explanations.

Also PRs belong to the review and CI system, everything needed to understand the code and its history should be staged in version control

Re: Idiot Proof Git

#157

Post by palata »

I think people mostly don't care, but I personally sign my commits.

And if you rebase, you lose the signature (well, maybe the person rebasing re-signs it). But then it means that my commits are not signed by me anymore.

Feels like an interesting point against rebase workflows to me, but nobody mentioned it, so maybe it's just me.

Re: Idiot Proof Git

#158

Post by cnity »

danpalmer wrote: post #2

Big fan of Git style guides in teams. We had one at Thread. It was common for engineers to come in and find we didn't do rebasing and find it weird, but we took the opinion that history should be exactly what you actually did, not some clean and idealised version of what you wish you had done. There are advantages and disadvantages to this, but having a defined approach was the most important aspect. Also the fact th…

If the employer I worked for started micro-managing the way I use my tools (that affects nobody else) I would consider leaving, honestly. If I rebase on a branch that hadn't been shared with someone else, why does it matter what my boss or team thinks about that approach?

Code styles are one thing, what I type into my terminal is another.

Re: Idiot Proof Git

#159

Post by anonuser123456 »

mattarm wrote: post #120
anonuser123456 wrote: post #100

Earlier quoted context omitted.

How do you lose data from a rebase?

A rebase creates new commits from old commits semi-automatically. Git then has no permanent record of the old commits, and even if you want to get back to them right away it requires some delicate git surgery. This is why you can't generally share work using a rebase workflow. It is not a big deal in practice in most every case, but in a version control system it is a little bit odd that rolling back such a fundament…

> even if you want to get back to them right away it requires some delicate git surgery.

The reflog tracks rebase commit history. No surgery required.

>This is why you can't generally share work using a rebase workflow.

Rebase of public facing commits is not discouraged due to data loss. It is discouraged due to the possibility of someone creating change sets off the published work, and then the update re-writing the history to change the merge-base, requiring a re-merge of their changes.

Re: Idiot Proof Git

#160

Post by make3 »

RadiozRadioz wrote: post #134
ccity88 wrote: post #90

Earlier quoted context omitted.

I know HN will absolutely tear me apart for recommending this, but I use GitHub desktop. It has all the bells and whistles of the CLI, but you can actually see and understand what's going on. As a Junior Engineer, a Senior Engineer recommended it to me. I thought he was joking at first, but he kindly reminded me that using a GUI app is completely fine and okay. We shouldn't stigmatise tools that make it easier to use…

The reason people on here tend to dislike those types of tools is because they've probably been the ones who had to fix the tangles people get themselves into by using those tools. Tools that obscure details in favor of simplicity are fine in some cases, but version control is an inherently complex problem domain where having those details is important. In my experience mentoring juniors new to git, those who are jus…

the other thing is that this likely doesn't work over ssh
Post reply on HN