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

41–50 of 210 posts

Re: Stacked Diffs with git rebase —onto

#41

Post by ptx »

sirsuki wrote: post #23
enbugger wrote: post #14

Earlier quoted context omitted.

Is there any good guide on how to solve the issue which OP solves?

You don’t really need docs as --update-refs does what the OP does automatically instead of manually like the OP does.

How? I tried recreating the scenario from the article (the section "First rebase –onto") and ran the first rebase with "--update-refs":

  $ git checkout feature-1
  $ git rebase --update-refs main
  Successfully rebased and updated refs/heads/feature-1.
  Updated the following refs with --update-refs:
   refs/heads/feature-2-base
But all it did was update feature-2-base. It still left feature-2 pointing to the old commits. So I guess it automates "git branch -f feature-2-base feature-1" (step 3), but it doesn't seem to automate "git rebase --onto feature-1 feature-2-base feature-2" (step 2).

Presumably I'm doing something wrong?

Re: Stacked Diffs with git rebase —onto

#43

Post by Fang_ »

Is there any reason besides merge commits ending up in history to not do this with merges instead? ie merge main into feature-1, then feature-1 into feature-2.

Sounds like using --update-refs would let you do all that in a single operation, but you still need to force-push and don't maintain an explicit merge/conflict resolution history, both of which could be considered sub-optimal for collaborative scenarios.

Re: Stacked Diffs with git rebase —onto

#44

Post by smcameron »

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…

For me, the answer is stgit. https://stacked-git.github.io/

Re: Stacked Diffs with git rebase —onto

#45

Post by bvdw »

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 interested, I made a tool that automates this workflow. The worfklow and tool are described here: https://github.com/bjvanderweij/dflock/

Re: Stacked Diffs with git rebase —onto

#46

Post by flr03 »

taejavu wrote: post #16
nrhrjrjrjtntbt wrote: post #13

Fun stuff, but I'll stick to trunk based dev, small PRs... thanks!

Stacking commits lets you do that without having to wait for each change to be reviewed/merged to the main branch before you iterate on top of those changes.

It's such a complicated way to work though, you start another set of changes then you go back addressing comments then you go back updating the stacked branch and you might need to do that few times... Teams should focus on getting stuff merged in and not create massive PRs that live forever, life becomes so much easier.

Re: Stacked Diffs with git rebase —onto

#47

Post by Hendrikto »

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…

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 git CLI is that bad. Once you learn some basic concepts, it makes a lot of sense and is pretty consistent.

Most problems people report stem from a refusal to learn the underlying structure and models. That is on them. And when using a different frontend, they don’t disappear either. They are just abstracted, to allow you to avoid learning them. But they are still there, and you will probably still need to know them at some point.

Re: Stacked Diffs with git rebase —onto

#48

Post by gcr »

YmiYugy wrote: post #38
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…

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

Re: Stacked Diffs with git rebase —onto

#49

Post by fwip »

happytoexplain wrote: post #27
nopurpose wrote: post #9

That particular case can be solved much easier by rebasing outer-most branch with `--update-refs` flag.

I came into the comments specifically to ask if this flag existed. I feel bad that the author developed this whole flow just because they didn't know about this, but that's pretty common with git.

I'm pretty sure the author was Claude, so don't feel too bad for it.

Re: Stacked Diffs with git rebase —onto

#50

Post by motoboi »

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?
Post reply on HN