zlacker

[return to "Stacked Diffs with git rebase —onto"]
1. polite+FBe[view] [source] 2025-12-05 11:10:35
>>flexdi+(OP)
This marker branch step feels like a workaround to a missing capability. It's something I can easily see one forgetting especially if they haven't been doing stacked diff workflows regularly.
◧◩
2. sublin+EGe[view] [source] 2025-12-05 11:49:37
>>polite+FBe
I agree it seems error prone. I'm not sure if I'm misunderstanding something, but I use `git cherry-pick` when I know I need to move commits around that might have conflicts. The problem with rebase can be that the user doesn't fully understand all the options being applied and end up with a "bad" merge.

I don't usually want to rewrite history. I just want the target branch with all my commits on top (I usually squash the feature branch into one commit anyway). I have yet to run into a situation where this isn't good enough.

If the branch diverges so much and has so many commits that this simpler approach doesn't work, that might not be a git problem, but a project management one. It's still always nice to know git has tools to get me out of a jam.

◧◩◪
3. 171862+Eri[view] [source] 2025-12-06 16:20:53
>>sublin+EGe
Rebase is just automated cherry-pick, so it ends being the same. The pick command in rebase is exactly that.

> and end up with a "bad" merge.

They end up with exactly the same merge when using cherry-pick directly?

> I don't usually want to rewrite history. I just want the target branch with all my commits on top

That's ... what rewriting history is?

[go to top]