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

Git Rebase for the Terrified

brethorsting.com

Post reply on HN
Print view View original

221–230 of 305 posts

Re: Git Rebase for the Terrified

#221

Post by game_the0ry »

nothrabannosir wrote: post #101
game_the0ry wrote: post #78

I have been contributing code for 10+ years, and I have worked on teams that did rebase and others that did not. Not once have a ever debugged a problem that benefited from rebase vs merge. Fundamentally, I do not debug off git history. Not once has git history helped debug outside of looking at the blame + offending PR and diff. Can someone tell me when they were fixing a problem and they were glad that they rebased…

Debugging from git history is a separate question from merge vs rebase. Debugging from history can be done with non-rebased merges, with rebased merges, and with squashed commits, without any noticeable difference. Pass `--first-parent` to git-log and git-bisect in the first two cases and it's virtually identical. My preference for rebasing comes from delivering stacked PRs: when you're working on a chain of individu…

> Debugging from git history is a separate question from merge vs rebase.

But the main benefit proponents or rebase say its for keeping the history clean which also makes it easier to pinpoint and offending commit.

Personally, a clean commit history was never something that made my job easier.

> Other than that this workflow allows you to create a history of very small, easily testable, easily reviewable, easily revertible commits, which makes debugging easier. But that's a downstream effect.

I would agree that it is important for commits to go from working state to working state as you are working on a task, but this is an argument for atomic commits, not about commit history.

Re: Git Rebase for the Terrified

#222

Post by throwaway7783 »

literallyroy wrote: post #215
throwaway7783 wrote: post #166

I avoid rebase like plague (perhaps because of my early experiences with it). I used to get continuous conflicts for the same commits again and again, and the store and replay kinda helped with it but not always. Merge always worked for me (once I resolve conflicts, thats the end of it). Now I always merge main into my feature branch and then merge it back to main when ready. Does it pollute the history? Maybe, but I…

I think the callout to squash first will be helpful (if your lots of commits aren’t good info themselves)

Perhaps. But you can see the DX of rebase is abysmal compared to merge. squash, rerere, force push, remember to push to remote before rebase, more coordination if multiple people are working on feature branch etc.

I still prefer merge. Its simple and gets out of my way as long as I dont care about purity of history

Re: Git Rebase for the Terrified

#223

Post by macintux »

game_the0ry wrote: post #221
nothrabannosir wrote: post #101

Earlier quoted context omitted.

Debugging from git history is a separate question from merge vs rebase. Debugging from history can be done with non-rebased merges, with rebased merges, and with squashed commits, without any noticeable difference. Pass `--first-parent` to git-log and git-bisect in the first two cases and it's virtually identical. My preference for rebasing comes from delivering stacked PRs: when you're working on a chain of individu…

> Debugging from git history is a separate question from merge vs rebase. But the main benefit proponents or rebase say its for keeping the history clean which also makes it easier to pinpoint and offending commit. Personally, a clean commit history was never something that made my job easier. > Other than that this workflow allows you to create a history of very small, easily testable, easily reviewable, easily reve…

> Personally, a clean commit history was never something that made my job easier.

How do you define "clean"? I've certainly been aided by commit messages that help me identify likely places to investigate further, and hindered by commit messages that lack utility.

Re: Git Rebase for the Terrified

#224

Post by parasti »

Been using git since 2008, and this looks more intimidating than helpful. git rebase takes a list of patches and applies them one by one on top of a given "base" commit. And that's it. It's not all this complicated git command soup. It's just patches. No objects, no sha1s, no metadata, no branches, just literal textual diffs applied in order. It's the dumbest and also one of the most powerful things about git if you care at all about a readable history. If you don't, that's fine, but in some circles, e.g. most (if not all) open source projects, patch management and history hygiene is a very important part of good collaboration.

Re: Git Rebase for the Terrified

#225

Post by cryptonector »

game_the0ry wrote: post #78

I have been contributing code for 10+ years, and I have worked on teams that did rebase and others that did not. Not once have a ever debugged a problem that benefited from rebase vs merge. Fundamentally, I do not debug off git history. Not once has git history helped debug outside of looking at the blame + offending PR and diff. Can someone tell me when they were fixing a problem and they were glad that they rebased…

Whenever I go spelunking in the history I always find clean, linear history, with small commits (where possible) to be much easier to understand and search than merges.

Re: Git Rebase for the Terrified

#226

Post by cryptonector »

rpcope1 wrote: post #139
game_the0ry wrote: post #78

I have been contributing code for 10+ years, and I have worked on teams that did rebase and others that did not. Not once have a ever debugged a problem that benefited from rebase vs merge. Fundamentally, I do not debug off git history. Not once has git history helped debug outside of looking at the blame + offending PR and diff. Can someone tell me when they were fixing a problem and they were glad that they rebased…

I have worked on several codebases where it was enforced that the commit be rebased off of whatever the main branch was, all units of work squashed to a single commit, and only "working" code be checked into the main branch. This gives you a really good linear history, and when you're disciplined about writing good final commit messages and tagging them to a ticket, it means bisecting to find challenging bugs later b…

I think one should be allowed to push commits that don't build or pass tests provided a) they are marked as such (so you can skip them sooner when bisecting) and b) the HEAD commit after each push does build and pass tests.

Re: Git Rebase for the Terrified

#227

Post by quacker »

ivanjermakov wrote: post #152
tomaytotomato wrote: post #41

Github is not Git but I find the Squash and Merge functionality on Github's Pull Request system means I no longer need to worry about rebasing or squashing my commits locally before rebasing. At work though it is still encouraged to rebase, and I have sometimes forgotten to squash and then had to abort, or just suck it up and resolve conflicts from my many local commits.

Squash is not Github specific and is part of git: git merge --squash

Right, but they are referring to configuration on a GitHub repository that can make squash merge automatic for all pull request merges.

e.g. When clicking the big green "Merge pull request" button, it will automatically squash and merge the PR branch in.

So then I don't need to remind or wait for contributors to do a squash merge before merging in their changes. (Or worse, forget to squash merge and then I need to fix up main).

Re: Git Rebase for the Terrified

#228

Post by convolvatron »

game_the0ry wrote: post #221
nothrabannosir wrote: post #101

Earlier quoted context omitted.

Debugging from git history is a separate question from merge vs rebase. Debugging from history can be done with non-rebased merges, with rebased merges, and with squashed commits, without any noticeable difference. Pass `--first-parent` to git-log and git-bisect in the first two cases and it's virtually identical. My preference for rebasing comes from delivering stacked PRs: when you're working on a chain of individu…

> Debugging from git history is a separate question from merge vs rebase. But the main benefit proponents or rebase say its for keeping the history clean which also makes it easier to pinpoint and offending commit. Personally, a clean commit history was never something that made my job easier. > Other than that this workflow allows you to create a history of very small, easily testable, easily reviewable, easily reve…

we're in the minority I think. I always find it easier to just debug a problem from first principles instead of assuming that it worked at some point and then someone broke it. often times that assumption is wrong, and often times the search for bad commit is more lengthy and less informative than doing the normal experimental process. I certainly admit that there are ases where the test is easily reproducible and bisect just spits out the answer, but that a seductive win. I certainly wouldn't start by reading the commit log and rewinding history until I at least had a general idea of the source of the problem, and it wasn't immediately obvious what to try next to get more information.

if you look at it as in investment in understanding the code base more than just closing the ticket as soon as possible, then the 'lets see what really going on here' approach makes more sense.

Re: Git Rebase for the Terrified

#229

Post by cryptonector »

hnben wrote: post #100
skipkey wrote: post #84

Earlier quoted context omitted.

I can give you an example of when I am glad I rebased. There have been many times I have been working on a feature that was going to take some time to finish. In that case my general workflow is to rebase against main every day or two. It lets me keep track of changes and handle conflicts early and makes the eventual merge much simpler. As for debugging I’ve never personally had to do this, but I imagine git bisect w…

> I can give you an example of when I am glad I rebased I think the question was about situations where you were glad to rebase, when you could have merged instead

That's hard to answer because I only rebase.

Re: Git Rebase for the Terrified

#230

Post by cryptonector »

appplication wrote: post #164
yawaramin wrote: post #110

Earlier quoted context omitted.

From what I can tell the vast majority of developers don't use git bisect and never will.

FWIW, having squashed merge commits also reduces the relevance of bisect. It can still be useful but it’s not necessarily as critical of a tool.

This. This is why small commits are nice. If you do that you might as well rebase. If you squash you lose.
Post reply on HN