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

Git rebase, what can go wrong

jvns.ca

Post reply on HN
Print view View original

201–210 of 404 posts

Re: Git rebase, what can go wrong

#201

Post by toast0 »

gwright wrote: post #190
bogeholm wrote: post #108

Earlier quoted context omitted.

I ser it the other way around - why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later. I prefer one commit to main per feature, a long with a good description on the GitHub PR. Sometimes I’ll branch out from a feature branch for the occasional and infamous ‘get CI working’ round of 10 one-line commits though, to not make it too muddy.

> why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later. Several reasons: * facilitates much better code review discussions * enables use of git bisect to locate bugs * allows for informative commit messages associated with the changes * communicates clearly to future self about why changes were made

> * enables use of git bisect to locate bugs

This is really only viable if each intermediate commit on a development branch is intended to be bug free. If that's the standard you and your team work with, that's fine, but it's not usually my standard; in a development branch, I may commit things that don't even compile, let alone work, if it's a good point to commit.

Re: Git rebase, what can go wrong

#202

Post by PaulDavisThe1st »

bigstrat2003 wrote: post #182
jzm2k wrote: post #58

Earlier quoted context omitted.

git-rebase is stupid because somebody doesn't know how to use it? I use it all the time and I really like how I can make garbage commits (wip, test) and then squash them into atomic commits which are easy to review and later on easy to bisect when inevitably mistakes happen. Sure I've fucked up too when I was learning on how to use it and those were some painful mistakes but only through using it and making those mis…

> git-rebase is stupid because somebody doesn't know how to use it? No, it's stupid because it's really common for people to fuck it up, and because the purported benefits (clean history) are not something which matters.

If I tell you it matters to me, will that change your mind?

You've told me that it doesn't matter to you, but that hasn't changed my mind.

It's not a matter of objective truth, it's a preference.

Re: Git rebase, what can go wrong

#203

Post by erik_seaberg »

joshribakoff wrote: post #123
dkarl wrote: post #92

Earlier quoted context omitted.

I think squash merges are a last resort heavy-handed tool for dealing with developers who refuse to clean up their commit history before merging. Most developers can do better by hand. Git history should tell a simple, understandable story of each change. For example: 1) refactor existing code, 2) add feature. Or 1) add missing tests, 2) refactor existing code, 3) add feature. But since you're working on the fly with…

You can simply ask “git log” to show you one coarse entry per Pr rather than “destroying” the more granular history

This. It bugs me that people permanently throw away details of changes rather than show just the log of merge commits.

Re: Git rebase, what can go wrong

#204

Post by PaulDavisThe1st »

Lio wrote: post #196
PaulDavisThe1st wrote: post #193

Earlier quoted context omitted.

> The solution is actually pretty easy. git rerere is the even easier solution.

I don't know, you still end up with a dirty branch full of commits you didn't write.

I was talking about a solution to the problem you quoted:

   > fixing the same conflict repeatedly is annoying

Re: Git rebase, what can go wrong

#205

Post by js2 »

diek wrote: post #160
js2 wrote: post #128

Earlier quoted context omitted.

Because unless it's the most trivial of features, you'll break it up into smaller commits which each explain what they are doing and make reviewing the change easier. As a simple example, I recently needed to update a json document that was a list of objects. I needed to add a new key/value to each object. The document had been hand edited over the years and had never been auto-formatted. My PR ended up being three c…

In general I agree with you, there are absolutely times where you want to retain commit history on a particular branch (although I try to keep the source tree from knowing about things like commit IDs). I would argue that those are by far the minority of PRs that I see. As I mentioned in another comment, _most_ PRs that I see have a ton of intermediary commits that are only useful for that branch/PR/review process (f…

> As I mentioned in another comment, _most_ PRs that I see have a ton of intermediary commits that are only useful for that branch/PR/review process (fixing tests, whitespace, etc).

Right, but that's only because developers don't amend and force push their commits to the PR branch as they receive feedback. Which is largely encouraged by GitHub being a terrible code review tool.

To me, git is part of the development process, it's not an extra layer of friction on top. So I compose my commits as I go. I find it helpful for recording what I'm thinking as I write the code. If I wait till the very end, I'll have forgotten some important bit of context I wanted to include. So during the day I may use the commits like save points. But before I push anything I'll often check out a new branch and create and incremental set of commits that have the change broken down into digestible pieces. And if I receive feedback, I'll usually amend those changes into the PR and force push it.

I'd like to add that I spend a lot of time cleaning up tech debt. And I deal with a ton of commits and PRs that don't explain themselves. So I'm really biased toward a clean development workflow because I hope to make the lives of those who come after me easier.

I was also trained on this workflow by being an early git contributor and it had extremely high standards for documenting its work. There's a commit from Jeff King that's a one line change with about six paragraphs of explanation.

There's no right answer here. I value the "meta" part of writing code. Not everyone does and that's okay.

Re: Git rebase, what can go wrong

#206

Post by bonzini »

toast0 wrote: post #201
gwright wrote: post #190

Earlier quoted context omitted.

> why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later. Several reasons: * facilitates much better code review discussions * enables use of git bisect to locate bugs * allows for informative commit messages associated with the changes * communicates clearly to future self about why changes were made

> * enables use of git bisect to locate bugs This is really only viable if each intermediate commit on a development branch is intended to be bug free. If that's the standard you and your team work with, that's fine, but it's not usually my standard; in a development branch, I may commit things that don't even compile, let alone work, if it's a good point to commit.

The point of the parent comment is exactly that you should clean up the history before merging to a public branch, so that you can use bisect, even if so far you had wip wip doh wip as the commit messages. The way to get there is to have a mix of proper and wip commits.

Re: Git rebase, what can go wrong

#207

Post by erik_seaberg »

Lio wrote: post #179
mablopoule wrote: post #13

Earlier quoted context omitted.

I actually hate squash merge because of all the noise it adds. Sure, the commit graph looks nicer, but it come with a terrible loss of information when doing git blame. I'm a big proponent of rebase and squash if it helps to make a commit more coherent, but we use squash merges by default in the current project I'm working on, and I die a little bit each time I try to understand what changes were related to a line wh…

Git blame confuses people even without squash merges. I've seen people forget to go back more than one commit and then blame the person who last indented a file instead of going back to the commit that actually wrote the code many times.

We shouldn’t tamper with code we don’t actually need to fix, it’s not a good use of time and it makes history less useful. Just because it doesn’t look like I wrote it doesn’t make it wrong.

Re: Git rebase, what can go wrong

#209

Post by mcv »

recursive wrote: post #5
jawns wrote: post #2

I like how Atlassian puts it: > The golden rule of rebasing > Once you understand what rebasing is, the most important thing to learn is when not to do it. The golden rule of git rebase is to never use it on public branches. https://www.atlassian.com/git/tutorials/merging-vs-rebasing#... For me, even though rebasing comes with some trappings, I still greatly prefer it to the alternative, which is to have merge commit…

Squash merges cut down the noise considerably.

They also cut down the signal.

Re: Git rebase, what can go wrong

#210

Post by [deleted] »

Lio wrote: post #170

> fixing the same conflict repeatedly is annoying This is usually caused by merging an upstream branch (e.g. develop) into your feature branch and then later trying rebase it. Effectively the commits you've merged in from develop undo the changes you've made in your feature branch. You fix them but the foreign commits undo the changes again. The solution is actually pretty easy. Use git rebase --interactive to remove…

[deleted]
Post reply on HN