Live data from Hacker News

Stacked Diffs with git rebase —onto

dineshpandiyan.com

31–40 of 210 posts

Re: Stacked Diffs with git rebase —onto

#32

Even if `--update-refs` didn't exist, my experience is that git can identify duplicate commits produced by rebase, and knows to skip them when rebasing the same commits to the same place again. Am I imagining that?

It definitely fast-forwards unchanged commits.

Re: Stacked Diffs with git rebase —onto

#33
post #25
post #22

Earlier quoted context omitted.

note that bookmarks don't float, unlike git branches, so if your pattern is to produce a lot of commits, you'll want something to keep your jj bookmarks pointing to the top of your pile of commits. this is less of a problem if you're more into the 1 change == 1 commit workflow.

There's a very common alias `jj tug` for this case: tug = ["bookmark", "move", "--from", "heads(::@- & bookmarks())", "--to", "@-"] It moves the nearest bookmark to the commit before the current one (which should be your working commit).

Thanks, I replaced my Frankenstein's monster of a parsing pipeline with this, very useful!

Re: Stacked Diffs with git rebase —onto

#35
post #5

I think ‘git rebase —-update-refs’ is the better way to go for this scenario

Sweet, looks like this is pretty new (2022).

Running a git command on one branch and multiple branches being affected is really unusual for me! This really does look like it is designed for just this problem, though. Simple overview: https://blog.hot-coffee.dev/en/blog/git_update_refs/

Re: Stacked Diffs with git rebase —onto

#36

Even if `--update-refs` didn't exist, my experience is that git can identify duplicate commits produced by rebase, and knows to skip them when rebasing the same commits to the same place again. Am I imagining that?

That works until you had to fix conflicts during the rebase and the commits are no longer identical.

Re: Stacked Diffs with git rebase —onto

#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’ve wondered if there is a psychological thing here: someone who spent time memorizing all the git nonsense may have some pride in that (which is earned, certainly), that introduces some mental friction in walking away???

Re: Stacked Diffs with git rebase —onto

#38
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.

Re: Stacked Diffs with git rebase —onto

#40
post #5

I 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?

I was reading this the other day when I came across this feature because I’m stacking PRs recently which I don’t usually do

https://andrewlock.net/working-with-stacked-branches-in-git-...

Another commenter posted this link which was a bit more succinct

https://blog.hot-coffee.dev/en/blog/git_update_refs/

There isn’t much to it though, you just go to the branch and run git rebase with the update refs flag.

Post reply on HN