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

291–300 of 305 posts

Re: Git Rebase for the Terrified

#291

Post by just6979 »

layer8 wrote: post #173
PaulDavisThe1st wrote: post #151

Earlier quoted context omitted.

You can make long lived feature branches work with rebase, you just have to regularly rebase along the way. I had a branch that lived for more than a year, ended up with 800+ commits on it. I rebased along the way, and the predictably the final merge was smooth and easy.

I don’t see how rebase frequency changes the problem of getting conflicts with some random commit within your long-lived branch, when doing a rebase. I rebase often myself, but I don’t understand the logic here.

If you rebase form main often, it keeps the difference to main quite small, so that when it comes time to do the final merge to main, it's either able to be fast-forwarded (keep it linear, good job!), or at least a very low risk of being conflicted (some people like merge commits, but at least your incoming branch will be linear). Because even though you might have commits that are a year old, initially branched from main from a year ago, their "base" has gradually become whatever main is _now_.

It's just like doing merges _from_ main during the lifetime of the branch. If you don't do any, you'll likely have lots of conflicts on the final merge. If you do it a lot, the final merge will go smooth, but your history will be pretzels all the way down.

In other words, frequent rebasing from main moves any conflicts from the future to "right now", but keeps the history nice and linear, on both sides!

Re: Git Rebase for the Terrified

#292

Post by just6979 »

PaulDavisThe1st wrote: post #233
layer8 wrote: post #198

Earlier quoted context omitted.

If you do a single rebase at the end, there is nothing to remember, you just get the same accumulated conflicts you also collectively get with frequent rebases. Hence I don’t understand the benefit of the latter in terms of avoiding conflicts.

You don't see a difference between dealing with conflicts within a few days of you doing the work that led to them (or someone else), and doing them all at once, perhaps months later?

This.

"If you do a single rebase at the end, there is nothing to remember, you just get the same accumulated conflicts you also collectively get with frequent rebases."

There is _everything_ to remember. You no longer have the context of what commits (on both sides) actually caused the conflicts, you just have the tip of your branch diffed against the tip of main.

"Hence I don’t understand the benefit of the latter in terms of avoiding conflicts."

You don't avoid conflicts, but you move them from the future to the present. If main is changing frequently, the conflicts are going be unavoidable. Why would you want to wait to resolve them all at once at the very end? When you could be resolving them as they happen, with all the context of the surrounding commits readily at hand. Letting the conflicts accumulate to be dealt with at the end with very little context just sounds terrifyingly inefficient.

Re: Git Rebase for the Terrified

#293

Post by just6979 »

cousin_it wrote: post #16
jillesvangurp wrote: post #10

Earlier quoted context omitted.

Rebase your local history, merge collaborative work. It helps to just relabel rebase as "rewrite history". That makes it more clear that it's generally not acceptable to force push your rewritten history upstream. I've seen people trying to force push their changes and overwrite the remote history. If you need to force push, you probably messed up. Maybe OK on your own pull request branches assuming nobody else is wo…

Maybe I'm old, but I still think a repository should be a repository: sitting on a server somewhere, receiving clean commits with well written messages, running CI. And a local copy should be a local copy: sitting on my machine, allowing me to make changes willy-nilly, and then clean them up for review and commit. That's just a different set of operations. There's no reason a local copy should have the exact same imp…

"There's no reason a local copy should have the exact same implementation as a repository, git made a wrong turn in this."

Who is forcing you to keep a local copy in the exact same configuration at upstream? Nothing at all is stopping you from applying your style to your repos. You're saying that not being opinionated about project structure is a "wrong turn"? I don't think so.

I think most "ground truth" open-source repos do end up operating like this. They're not letting randos push branches willy-nilly and kick off CI. Contributors fork it, work on their own branches, open a PR upstream (hence that name: PULL Request), reviews happen, nice clean commits get merged to the upstream repository that is just being a repository on a server somewhere running CI.

Re: Git Rebase for the Terrified

#294

Post by g-b-r »

globular-toast wrote: post #280
g-b-r wrote: post #278

Earlier quoted context omitted.

https://stackoverflow.com/questions/66449211/a-lock-file-alr... happens fairly easily, and at least years ago it was not easy to figure out how to solve it. I think I did run in other bugs that did appear to have messed up the repository. > like I said, no command in git can modify or delete a commit. Well, you can end up losing commits by playing with the reflogs or deleting branches (if you haven't checked out the…

I've never run into index.lock nor had anyone else run into it after it being the "git guy" at various employments. Garbage collection is a thing, of course, but it could be completely disabled if necessary. Most people don't bother because the defaults are sensible in virtually all cases. Almost all git problems people have are because they don't know about the reflog and don't understand that git is fundamentally a…

> I've never run into index.lock nor had anyone else run into it after it being the "git guy" at various employments.

Weird, to me it happened several times

> Garbage collection is a thing, of course, but it could be completely disabled if necessary

Yeah, I do set reflogs to not expire

Re: Git Rebase for the Terrified

#295

Post by _flux »

skulk wrote: post #137
_flux wrote: post #26

Earlier quoted context omitted.

I think I'd love to use Jujutsu, but I enjoy Magit (for Emacs) too much to entertain the thought of switching :/. Besides, Magit rebasing is also pretty sweet.

I used to think like this, but then I realized: jj-mode.el exists[0] and you can still use magic since it's still a git repo underneath. Seriously, don't let this hold you back. [0]: https://github.com/bolivier/jj-mode.el

I took a look at both, and I think I'd need the jj split function (comparable to staging individual lines) to be implemented in jj-mode to match my use of magit.

Re: Git Rebase for the Terrified

#296

Post by jon-wood »

unshavedyak wrote: post #197
Liskni_si wrote: post #184

Earlier quoted context omitted.

You do if you find yourself in a team where PRs are squash-merged. :-(

Does that happen on merge or before PR creation? I thought the setting only applied it when you hit the merge button, so you'd still have commits prior to the merge. Though that won't help if someone pre-squashes them :s

As the mythical doctor once said, "don't do that". My sympathies if you're on a team that requires it.

Re: Git Rebase for the Terrified

#298

Post by drysine »

bastardoperator wrote: post #207
drysine wrote: post #195

Earlier quoted context omitted.

>each commit nominally should work Except it can be the result of 10 squashed commits.

Which is the entire point of it. Why should I look at ten commits when I can look at one and get the same exact data? Why should I pollute my production history for what a is likely a bunch of debugging commits? The branch is a scratchpad, you should feel empowered within your own branch, rebase allows you to be lazy in the development cycle while presenting a nice clean set of changes at the end of it.

>Why should I look at ten commits when I can look at one and get the same exact data?

For the same reason you have your production history instead of zip file with code)

>while presenting a nice clean set of changes at the end of it

The set, yes, not a single squashed commit.

>The branch is a scratchpad, you should feel empowered within your own branch, rebase

Yes, amend, fixup, rebase. Make it a nice set of small commits.

Re: Git Rebase for the Terrified

#299

Post by drysine »

cluckindan wrote: post #265
cmrdporcupine wrote: post #256

Earlier quoted context omitted.

Which wreaks havoc with githubs shitty code review tool. Which is an argument against GitHub, not clean commit history

Yep. Rebase rewrites history and all the PR review comments vanish.

Gitlab seems fine with it

Re: Git Rebase for the Terrified

#300

Post by skulk »

_flux wrote: post #295
skulk wrote: post #137

Earlier quoted context omitted.

I used to think like this, but then I realized: jj-mode.el exists[0] and you can still use magic since it's still a git repo underneath. Seriously, don't let this hold you back. [0]: https://github.com/bolivier/jj-mode.el

I took a look at both, and I think I'd need the jj split function (comparable to staging individual lines) to be implemented in jj-mode to match my use of magit.

You can already do this if you just open up your change in magit and repeatedly commit pieces of it. I agree it's not super ergonomic since it leaves an old change behind and it requires using magit on top of jj-mode but it's 90% of the way there.
Post reply on HN