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

131–140 of 210 posts

Re: Stacked Diffs with git rebase —onto

#131

Post by IshKebab »

taejavu wrote: post #105
IshKebab wrote: post #73

Eh I just use `git rebase -i` and delete the commits I don't want. Much easier to think about. But the real problem with this workflow is that neither Github nor Gitlab support it at all. Not even Forgejo does. Which blows my mind because is such an obvious way to work. As far as I know only Tangled actually supports it, but unfortunately Tangled is tangled up in its own weird federation ideas. There's no way to priv…

I’m not sure what you mean, I stack PRs all the time with GitHub - select the earlier branch as the merge target instead of the main branch.

That doesn't work for cross-repo PRs which is by far the most common way of creating PRs on GitHub (at least for open source stuff).

Re: Stacked Diffs with git rebase —onto

#132

Post by steveklabnik »

conradludgate wrote: post #128
oscillonoscope wrote: post #91

Earlier quoted context omitted.

I more or less use the method described [here]( https://steveklabnik.github.io/jujutsu-tutorial/advanced/sim... ) for branches. One thing I do change is that I set the bookmark to an empty commit that serves as the head of each branch. When I am satisfied with a commit on head and want to move it to a branch I just `jj rebase -r @ -B branch`. When I want to create a new branch it's just `jj new -A main -B head` and `…

_Every time I see one of these nifty jj tricks or workarounds I find myself wondering, “why not just use git?”_

How would you do this in stock git?

Re: Stacked Diffs with git rebase —onto

#133

Post by steveklabnik »

wakawaka28 wrote: post #130
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…

This particular tip is basic. It just describes how to copy changes from one branch to another with one kind of rebase. But there's always someone who is learning git for the first time and may not even know how it's used. Git is simple enough and has features and capabilities that jj does not have. Contrary to popular belief, git is not hard to use. I refuse to use any "simpler" system that is slower or less feature…

submodules aren't native with jj, you use git commands to manage them, and it works fine. Eventually there'll be some sort of native support.

worktrees are called "workspaces" in jj, but are the same.

A lot of people find jj easier to have good commit hygiene with, and find it simpler and more powerful, not less. But that said, if you're happy with git, you should continue to use it.

Re: Stacked Diffs with git rebase —onto

#134

Post by saint_yossarian »

happytoexplain wrote: post #58
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.

They meant merging the other way, i.e. merging the new changes from main into the stacked feature branches.

This is functionally the same as rebasing, except that the new changes show up at the tip of the commit chain rather than the base. And because it doesn't rewrite history you don't need to force-push.

Re: Stacked Diffs with git rebase —onto

#135

Post by yegle »

steveklabnik wrote: post #119
yegle wrote: post #92

Earlier quoted context omitted.

jj does not support git submodules, this precludes even a casual use on my own personal repo.

It just means that you use git commands to update your submodules, jj still works for the rest of the repo just fine.

I have a repo where main has no submodules and a branch has submodules. Switching between then breaks everything...

Re: Stacked Diffs with git rebase —onto

#136

Post by brooke2k »

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…

I don't think it's pride, more that I don't see the problem that it solves for me. I don't find that git gets in my way at all, and I don't find it confusing. It's a pretty transparent tool that I use every day and hardly notice.

I don't mind other people using jj, but I simply don't feel a need to try it. There's nothing prideful about that, it's just pragmatism.

Re: Stacked Diffs with git rebase —onto

#137

Post by wakawaka28 »

steveklabnik wrote: post #133
wakawaka28 wrote: post #130

Earlier quoted context omitted.

This particular tip is basic. It just describes how to copy changes from one branch to another with one kind of rebase. But there's always someone who is learning git for the first time and may not even know how it's used. Git is simple enough and has features and capabilities that jj does not have. Contrary to popular belief, git is not hard to use. I refuse to use any "simpler" system that is slower or less feature…

submodules aren't native with jj, you use git commands to manage them, and it works fine. Eventually there'll be some sort of native support. worktrees are called "workspaces" in jj, but are the same. A lot of people find jj easier to have good commit hygiene with, and find it simpler and more powerful, not less. But that said, if you're happy with git, you should continue to use it.

What is the most useful feature of jj that you think git doesn't have?

Re: Stacked Diffs with git rebase —onto

#138

Post by wild_egg »

steveklabnik wrote: post #132
conradludgate wrote: post #128

Earlier quoted context omitted.

_Every time I see one of these nifty jj tricks or workarounds I find myself wondering, “why not just use git?”_

How would you do this in stock git?

I might just not be following correctly but committing in git just carries the branch along for the ride, so there's nothing to do in git for this scenario.

IIRC forcing some specific branch name to point to my changes with `jj` was non-obvious and what made me give up and go back to git when I tried it last year.

Re: Stacked Diffs with git rebase —onto

#139

Post by martinvonz »

wakawaka28 wrote: post #137
steveklabnik wrote: post #133

Earlier quoted context omitted.

submodules aren't native with jj, you use git commands to manage them, and it works fine. Eventually there'll be some sort of native support. worktrees are called "workspaces" in jj, but are the same. A lot of people find jj easier to have good commit hygiene with, and find it simpler and more powerful, not less. But that said, if you're happy with git, you should continue to use it.

What is the most useful feature of jj that you think git doesn't have?

I can pick only one? Perhaps automatic rebasing then, i.e. that all descendant commits and bookmarks (branches) are automatically updated when you rewrite a commit, e.g. by amending into it.

Re: Stacked Diffs with git rebase —onto

#140

Post by dfawcus »

Even for 'normal' rebases of a multi-commit series (without named feature branches), I habitually use the --onto form. It is simply easier to conceptualise what is happening if one is explicit about the 3 references.

As such, using it for the situation described in the piece then becomes a trivial matter, especially if one also habitually runs a graph viewer - I generally have one or more instances of gitk running all the time.

Post reply on HN