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

161–170 of 305 posts

Re: Git Rebase for the Terrified

#161

Post by chuckadams »

friedbeef wrote: post #147
languid-photic wrote: post #129

Earlier quoted context omitted.

I manage a maintained fork and periodically rebase our changes on top of upstream. In this case, rebasing is nice because our changes stay in a contiguous block at the top (vs merging which would interleave them), so it's easy for me and others to see exactly where our fork diverges.

Doesn’t that mean you have to fix all the merge conflicts introduced by your commits on every rebase though?

Git has gotten pretty smart about that recently: once you resolve a conflict, if you get the same conflict again it automatically resolves it the same way. Works for both rebase and merge.

Re: Git Rebase for the Terrified

#162

Post by game_the0ry »

d_watt wrote: post #88
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…

Once we had a slowdown in our application that went unadressed for a couple of months. Using git bisect to binary search across a bunch of different commits and run a perf test, every commit being a "good" historical commit allowed that to be much easier, and I found the offending commit fast.

Ok, I see. This is a use case I did not think about. Worthy of a blog post, I think.

Besides testing for a perf slow down, any other use cases for git bisect + rebase?

Re: Git Rebase for the Terrified

#163

Post by rendaw »

fc417fc802 wrote: post #55
smartmic wrote: post #40

Earlier quoted context omitted.

Let me expand on this with a link to the article "Rebase Considered Harmful" [0]. I also prefer Fossil to Git whenever possible, especially for small or personal projects. [0] https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

> Surely a better approach is to record the complete ancestry of every check-in but then fix the tool to show a "clean" history in those instances where a simplified display is desirable and edifying From your link. The actual issue that people ought to be discussing in this comment section imo.

Isn't this just `--first-parent`? I think that should probably be the default in git. Maybe the only way this will happen is with a new SCM.

But the git authors are adamant that there's no convention for linearity, and somehow extended that to why there shouldn't be a "theirs" merge strategy to mirror "ours" (writing it out it makes even less sense, since "theirs" is what you'd want in a first-parent-linear repo, not "ours").

Re: Git Rebase for the Terrified

#164

Post by appplication »

yawaramin wrote: post #110
any1 wrote: post #99

Earlier quoted context omitted.

> Fundamentally, I do not debug off git history. Are you saying that you've never used git bisect? If that's the case, I think you're missing out.

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.

Re: Git Rebase for the Terrified

#165

Post by pluralmonad »

ratchetclank wrote: post #66
hhjinks wrote: post #54

Earlier quoted context omitted.

Which branch your work was done on is noise, not signal. There is absolutely zero signal lost by rebasing, and it prunes a lot of noise. If your branch somehow carries information, that information should be in your commit message.

I disagree, without this info, I can't easily tell if any commit is part of a feature or is a simple hotfix. I need to rely on the commiter to include the info in the commit message, which is almost always not the case.

But you are still relying on them to name the branch in such a way it encodes that info. It is unclear why this is superior to messages in commits.

Re: Git Rebase for the Terrified

#166

Post by throwaway7783 »

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 Ive never looked. It does not matter to our team.

Re: Git Rebase for the Terrified

#167

Post by WolfeReader »

bheadmaster wrote: post #145
jimbobimbo wrote: post #141

Rebase is easy and not terrifying. Here's a 1k word article on how to do it correctly. Or just do a merge and move on with your life.

If you want to have a linear history on main, either always rebase your branch onto main, or merge but only accept squashed commits onto main.

I would prefer to have accurate history over linear "history".

Re: Git Rebase for the Terrified

#168

Post by bluGill »

skipkey wrote: post #84
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 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 used hg (mercurial) before git. Every time I see someone make an argument like yours I think "only because git's merge/branch model is bad and so you need hacks to make it acceptable".

Git won, which is why I've been using it for more than 10 years, but that doesn't mean it was ever best, it was just most popular and so the rest of the eco system makes it worth it accepting the flaws (code review tools and CI system both have much better git support - these are two critical things that if you use anything else will work against you).

Re: Git Rebase for the Terrified

#169

Post by WolfeReader »

magicalhippo wrote: post #111
spiffyk wrote: post #61

Earlier quoted context omitted.

Git's "ours"/"theirs" terminology is often confusing to newcomers, especially when from a certain (incorrect, but fairly common) point of view their meaning may appear to be swapped between merge and rebase. I think in an attempt to make the terminology less confusing UIs tend to reinvent it, but they always fail miserably, ending up with the same problem, just with slightly different words. This constant reinvention…

We use SVN at work and it's a nightmare there too, "mine" and "theirs" and whatnot. I frequently end up looking at historical versions just to verify which is which. If I have a merge conflict I typically have to be very conscious about what was done in both versions, to make sure the combination works. I wish for "working copy" and "from commit 1234 (branch xyz)" or something informative, rather than confusing catch…

Please tell me you are using Git-SVN or Hg-SVN. Using bare SVN as a client hasn't been necessary in over a decade.
Post reply on HN