I believe the author would love stg: https://stacked-git.github.io/guides/tutorial/#patches
Stacked Diffs with git rebase —onto
11–20 of 210 posts
Re: Stacked Diffs with git rebase —onto
#12Jujutsu comes in handy here for the same usecase: https://github.com/jj-vcs/jj https://www.stavros.io/posts/switch-to-jujutsu-already-a-tut... Also found https://github.com/gitbutlerapp/gitbutler
The main issue I kept having when trying to do this with just git is then managing all the branch names to be attached to the right moved commits, so that my stack could be reviewable on github's open PRs. Does jj help with that at all? I've experimented a bit with git-town.com (OSS) and now everyone at $DAYJOB uses graphite.com (SaaS) which does that part very well.
It’s one of the core features that rebases, including branch names (bookmarks in jj) work ‘correctly’. You can rebase whole dags, including merges, with multiple named heads with just one jj rebase -b.
Re: Stacked Diffs with git rebase —onto
#13Fun stuff, but I'll stick to trunk based dev, small PRs... thanks!
Re: Stacked Diffs with git rebase —onto
#14I think ‘git rebase —-update-refs’ is the better way to go for this scenario
Is there any good guide on how to solve the issue which OP solves?
Re: Stacked Diffs with git rebase —onto
#15This 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.
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.
Re: Stacked Diffs with git rebase —onto
#16Fun 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.
Re: Stacked Diffs with git rebase —onto
#17We use graphite at work to automate this workflow. The whole point is avoid this toil.
Re: Stacked Diffs with git rebase —onto
#18Fun 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.
True. I find I rarely need it: standard rebase or merge do the trick. If they don't the review cycle or PR size may be too high. Super rare I need onto. So rare I look up how to do it when I do.
Re: Stacked Diffs with git rebase —onto
#19That particular case can be solved much easier by rebasing outer-most branch with `--update-refs` flag.
Yep. I set this in .gitconfig
Re: Stacked Diffs with git rebase —onto
#20This 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.
The capability is there.
Just use git rebase --update-refs ...