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

Stacked Diffs with git rebase —onto

dineshpandiyan.com

Post reply on HN
Print view View original

81–90 of 210 posts

Re: Stacked Diffs with git rebase —onto

#81

Post by happytoexplain »

mytailorisrich wrote: post #63

Instead of "stacked diffs", isn't the more "continuous integration" solution to split a big feature into small chunks that actually get merged? Having to rebase again and again is a symptom that a dev branch is living for too long.

This problem isn't specific to cases where you are rebasing "again and again". Just needing to do a single rebase (e.g. prior to opening a PR) for a stacked feature is enough to need a solution.

And, as others have pointed out, the modern solution is `--update-refs`, so there's no need for complicated workflows any more anyway.

If you mean rebasing as each PR in the stack is merged, most Git platforms have the ability to do that automatically.

Re: Stacked Diffs with git rebase —onto

#82

Post by Hendrikto »

quietbritishjim wrote: post #61
Hendrikto wrote: post #47

Earlier quoted context omitted.

It’s a bit like qwertz. Sure, it is not optimal, there are better alternatives available. But it is good enough, and it is universal. That trumps a 5% typing improvement on my own custom keyboard layout at the cost of not being able to use my coworkers keyboard. Also, I dislike all of the alternate git frontends I tried, because they are opinionated in a way they clash with my workflow. Moreover, I don’t think the gi…

> Most problems people report stem from a refusal to learn the underlying structure and models. It's very easy to fall into the trap of believing this: git's implementation fits together neatly enough that it feels like the best you could do. Like, yes it's complex, but surely that's just intrinsic complexity of the problem? (Also, I think we all sometimes feel like someone with a different view must just not know as…

> It's very easy to fall into the trap of believing this: git's implementation fits together neatly enough that it feels like the best you could do.

I explicitly said that git IS NOT the best we can do. But it is universal and good enough. Not nearly as bad as some people make it out to be.

Re: Stacked Diffs with git rebase —onto

#83

Post by happytoexplain »

glenjamin wrote: post #72
mytailorisrich wrote: post #63

Instead of "stacked diffs", isn't the more "continuous integration" solution to split a big feature into small chunks that actually get merged? Having to rebase again and again is a symptom that a dev branch is living for too long.

I’m amazed that this comment is so low down Stacked diffs seems like a solution to managing high WIP - but the best solution to high WIP is always to lower WIP Absolutely everything gets easier when you lower your work in progress.

This seems idealistic. It's very normal to be working on a feature that depends on a not-yet-merged feature.

Re: Stacked Diffs with git rebase —onto

#84

Post by mytailorisrich »

happytoexplain wrote: post #81
mytailorisrich wrote: post #63

Instead of "stacked diffs", isn't the more "continuous integration" solution to split a big feature into small chunks that actually get merged? Having to rebase again and again is a symptom that a dev branch is living for too long.

This problem isn't specific to cases where you are rebasing "again and again". Just needing to do a single rebase (e.g. prior to opening a PR) for a stacked feature is enough to need a solution. And, as others have pointed out, the modern solution is `--update-refs`, so there's no need for complicated workflows any more anyway. If you mean rebasing as each PR in the stack is merged, most Git platforms have the abilit…

No, I mean small chunks that are actually merged instead of having a stack of them floating around.

A rebase before a merge can always happen, of course. But there are not stacked commits then it is just a standard rebase of your small chunk and that's it. And this will also have a shorter life than a stack so rebases will be rarer and simpler.

Re: Stacked Diffs with git rebase —onto

#85

Post by baq »

gcr wrote: post #48
YmiYugy wrote: post #38

Earlier quoted context omitted.

For me the answer is lazygit. I rarely use the git cli. I don't want to learn the jj cli and the TUI wrappers for jj seem less polished.

jjui is great, give it a try! i went from being a "jj cli power user" to relying on jjui for all of my complex rebase needs so quickly that i now have to read the man page to recall basic commands

can confirm jjui is super nice, except I've never been a jj cli power user ;)

Re: Stacked Diffs with git rebase —onto

#86

Post by bilalq »

swaits wrote: post #37

Every time I see one of these nifty git tricks or workarounds I find myself wondering, “why not just use jj?” You get a nicer, significantly simpler interface. You don’t need any tricks. You don’t have to google how to work yourself out of a bad state, ever. And you get near-perfect git compatibility (ie you can use jj on a shared git repo, doing all the same things, and your teammates won’t know the difference). I’v…

I have one and a half decades of muscle memory burned in with inoremap jj `^

It's not something I can just shift away from.

Re: Stacked Diffs with git rebase —onto

#87

Post by tcoff91 »

IshKebab wrote: post #79
swaits wrote: post #37

Every time I see one of these nifty git tricks or workarounds I find myself wondering, “why not just use jj?” You get a nicer, significantly simpler interface. You don’t need any tricks. You don’t have to google how to work yourself out of a bad state, ever. And you get near-perfect git compatibility (ie you can use jj on a shared git repo, doing all the same things, and your teammates won’t know the difference). I’v…

> why not just use jj 1. It's very new; I haven't had time to learn it properly yet. 2. It's very new and tooling doesn't support it well, e.g. VSCode. There aren't many GUIs yet. 3. I tried it once co-locating with Git and you definitely can't use both at the same time, even if it can use a `.git` directory. It ended up in a huge mess. I'm definitely in favour of better-than-Git alternatives but I don't think it's r…

There is a vscode jj gui extension

Re: Stacked Diffs with git rebase —onto

#88

Post by tcoff91 »

hansvm wrote: post #70
swaits wrote: post #37

Every time I see one of these nifty git tricks or workarounds I find myself wondering, “why not just use jj?” You get a nicer, significantly simpler interface. You don’t need any tricks. You don’t have to google how to work yourself out of a bad state, ever. And you get near-perfect git compatibility (ie you can use jj on a shared git repo, doing all the same things, and your teammates won’t know the difference). I’v…

> introduces some mental friction in walking away??? I don't think it's just mental friction. Suppose you've learned git well enough that everything you do in it is automatic and fast, and the things which aren't fast by default you've built aliases and tooling for over the years. Yes, starting from ground zero you might want something like jj, but at the current point in your life you're not starting from ground zer…

But with jj there are better workflows that aren’t really doable with git.

Re: Stacked Diffs with git rebase —onto

#89

Post by happytoexplain »

mytailorisrich wrote: post #84
happytoexplain wrote: post #81

Earlier quoted context omitted.

This problem isn't specific to cases where you are rebasing "again and again". Just needing to do a single rebase (e.g. prior to opening a PR) for a stacked feature is enough to need a solution. And, as others have pointed out, the modern solution is `--update-refs`, so there's no need for complicated workflows any more anyway. If you mean rebasing as each PR in the stack is merged, most Git platforms have the abilit…

No, I mean small chunks that are actually merged instead of having a stack of them floating around. A rebase before a merge can always happen, of course. But there are not stacked commits then it is just a standard rebase of your small chunk and that's it. And this will also have a shorter life than a stack so rebases will be rarer and simpler.

Oh, yes - but this is more about your situation than your style. Sometimes a feature is large and varied enough to beg multiple PRs, yet singular enough that you are not developing them serially (i.e. as you work on later parts, you are changing earlier parts). Most of the time this isn't the case.

Re: Stacked Diffs with git rebase —onto

#90

Post by bvdw »

motoboi wrote: post #50
bvdw wrote: post #45

I've settled on a workflow that reverses the situation. I simply commit all my work to the main branch and cherry pick commits into temporary feature branches only when submitting PRs. This way I only need to worry about maintaining a single consistent lineage of commits. I've been using this workflow for about a year now and find it to be much easier than juggling and rebasing feature branches. In case anyone's inte…

How many people on the team?

I work in a small team, about five people.
Post reply on HN