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

181–190 of 435 posts

Re: Idiot Proof Git

#181

Post by darkwater »

aulin wrote: post #156
lelandfe wrote: post #144

Earlier quoted context omitted.

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

I agree and this sounds super neat but in reality it's pretty complicated to keep that boundary and not leak info from one side to the other. I mean, when you open a PR you will probably describe the rationale for the change and why you had to touch files A,B & C (if it's not obvious). You can and you should replicate that info in a multi-line commit message but sometimes through code review you reshape the code structure or even some of the requirements (most probably because there was some initial misunderstanding). So, since we are humans, it's normal to take shortcuts when we did already "a good enough job" and leave out those small details.

Anyway I agree that we should aim at this: PRs are in the CI/review land, why a commit is like it is, should go into VC.

Re: Idiot Proof Git

#182

Post by opsy_ »

seba_dos1 wrote: post #126
mattarm wrote: post #120

Earlier quoted context omitted.

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…

> and even if you want to get back to them right away it requires some delicate git surgery. `git reflog` to get the old commit ID, and then `git reset --hard `. Seems more like "basic everyday git operations" than "some delicate git surgery".

Many past confused teammates of mine I've dropped in to help would disagree. reflog and reset, for better or worse, require what seems to be above-average comfort with git.

Re: Idiot Proof Git

#183

Post by krinchan »

dec0dedab0de wrote: post #78
idop wrote: post #52

Earlier quoted context omitted.

At the end of the day everything depends on the organization. In a hectic startup where requirements change on an hourly basis and releases are made several times a day, I would absolutely insist on keeping the log linear and as clear as possible. Tags are important, of course, but they're not that useful for analyzing a repository. When I say "the evolution of the product" I really mean "the "evolution of the code".…

When I say "the evolution of the product" I really mean "the "evolution of the code". When a small feature branch with 5 commits - four of which say "wip" and the last one says "added color support" - gets merged as is, and all relevant information is held hostage by whatever Git platform the company is using this week and not inside the repository itself, the log is not useful to me regardless of any strategy. Yes,…

    git add .; and git commit --amend --no-edit; git push origin --force
Rarely, I have to do pipeline work on repositories. You'd normally see twenty "Fix Jankins Issue" commits on the main branch because of some nonsense that only happens when you deploy UAT or whatever. Once I learned this little gem, this is also how I manage my feature branches mostly. But also my employer's fleet of laptops has been aging and I've had to do 3 swap outs this year, so I like to keep my in progress work pushed up just in case.

Re: Idiot Proof Git

#184

Post by RadiozRadioz »

evandale wrote: post #154
Izkata wrote: post #128

Earlier quoted context omitted.

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

Bisect will let you find the big squash commit that caused the regression, but lots of the information about why the change happened was lost during the squash. Often it's sufficient to just know the broad feature that the change was in aid of, but you're out of luck if you're diagnosing anything subtle. Bisect works better with smaller commits.

Re: Idiot Proof Git

#185

Post by sdiacom »

make3 wrote: post #160
RadiozRadioz wrote: post #134

Earlier quoted context omitted.

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

It does. GitHub has been soft-deprecating HTTP for years now.

Re: Idiot Proof Git

#186

Post by theonething »

cube2222 wrote: post #169
cnity wrote: post #155

Earlier quoted context omitted.

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

This is basically solved by squashing each PR on merge and having a good PR title + description.

This is my habit and I advocate for it on new teams. It's so simple and effective. Why make it complicated?

Re: Idiot Proof Git

#187

Post by dullcrisp »

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…

> they probably don't know about -a

How are you going to keep them from learning about -a?

Re: Idiot Proof Git

#188

Post by Izkata »

evandale wrote: post #154
Izkata wrote: post #128

Earlier quoted context omitted.

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

It works, but it works better when you have the original 10000 commits. You can tell exactly what the committer was attempting when the bug was introduced. It may have been as a fix to something else, it may have been a typo when linting, it may even have been been intentional and the bug report is wrong.

Other comments I made on another recent git post:

https://news.ycombinator.com/item?id=33395616

https://news.ycombinator.com/item?id=33392624

Re: Idiot Proof Git

#189

Post by OkayPhysicist »

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…

You didn't mention the fact that the GUI tools often lack functionality that's present in the CLI. Like git notes (looking at you, GitHub, who previously HAD notes support, but dropped it) or worktrees (Sourcetree lets you view worktrees, but provides no interface for interacting with them as worktrees, rather than just another repo). Or they hide basic functionality, like git ammend, or give less useful error handling advice than git itself (Sourcetree, I love your commit graph, but your error messages are worthless).

Re: Idiot Proof Git

#190

Post by montebicyclelo »

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…

For a nice record of history - rather than squashing all of the smaller commits into a single commit for a given feature, and then rebasing (which makes it less easy to have small commits with specific explanations that add together to create a feature), something like semantic-release [1] could be used, which autogenerates release notes based on commit messages.

[1] https://github.com/semantic-release/semantic-release

Post reply on HN