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

51–60 of 210 posts

Re: Stacked Diffs with git rebase —onto

#51

Post by gcr »

baq wrote: post #12
ndr wrote: post #8

Earlier quoted context omitted.

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.

To expand: In jj, bookmarks point to "changes," not commits. Rebases, history manipulations, etc. preserve change ID, so this "just works."

Re: Stacked Diffs with git rebase —onto

#52

Post by JimDabell »

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…

You might like Jujutsu – you commit without being on any branch and then later you can decide where and how you put things onto branches.

Re: Stacked Diffs with git rebase —onto

#53

Post by bvdw »

JimDabell wrote: post #52
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…

You might like Jujutsu – you commit without being on any branch and then later you can decide where and how you put things onto branches.

Interesting, I'll be sure to check it out. It sounds pretty similar to the tool I built which lets you edit a "plan" in a text editor to assign commits to feature branches - the plan is saved so it can be amended continuously.

Re: Stacked Diffs with git rebase —onto

#54

Post by Xophmeister »

the_gipsy wrote: post #3

I usually just `git rebase origin/main -i` after the base branch has been merged there, and this means I need to explicitly drop the merged commits, but I can inspect what's happening.

Yeah, I do this too: The `--onto` solution feels a bit too magical at times and an interactive rebase is pretty clear about what's happening.

Re: Stacked Diffs with git rebase —onto

#55

Post by happytoexplain »

ptx wrote: post #41
sirsuki wrote: post #23

Earlier quoted context omitted.

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…

First, you don't need the extra "marker" commit. This flag obviates the entire workflow.

Second, you run it on the outermost branch: feature 2. It updates all refs in the chain.

Re: Stacked Diffs with git rebase —onto

#56

Post by mhw »

ptx wrote: post #41
sirsuki wrote: post #23

Earlier quoted context omitted.

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…

Yeah, you need to rebase the tip of the feature branch stack. git will then update all the refs that point to ancestor commits that are moved. So in this case

    $ git rebase --update-refs main feature-2

Re: Stacked Diffs with git rebase —onto

#57

Post by url00 »

imron wrote: post #20
politelemon wrote: post #7

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.

The capability is there. Just use git rebase --update-refs ...

Wow you aren't wrong, the first blog post on Google talking about this is exactly what this complicated method does just built-in.

Re: Stacked Diffs with git rebase —onto

#58

Post by happytoexplain »

Fang_ wrote: post #43

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.

The use case is that they are not ready to merge yet.

Re: Stacked Diffs with git rebase —onto

#59

Post by max_k »

smcameron wrote: post #44
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/

Oh, there's another stgit user! ^5 Coming from darcs, I couldn't use git until stgit came along, and today, it's one of those few tools I can't imagine working without. Nothing else matches my way of code hacking. So often, I watch people making a big mess with git, and I always recommend stgit to them, so they can post proper and reviewable branches for merging. But in all these years, I could never convince anybody.

Re: Stacked Diffs with git rebase —onto

#60

Post by onionisafruit »

nopurpose wrote: post #9

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

Thanks. This is going to be so useful, but it pains me to know I could have been using —update-refs for the last three years.

I used to dutifully read release notes for every git release, but stopped at some point. Apparently that point was more than three years ago.

Post reply on HN