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

171–180 of 210 posts

Re: Stacked Diffs with git rebase —onto

#171

Post by [deleted] »

martinvonz wrote: post #169
1718627440 wrote: post #166

Earlier quoted context omitted.

I think this is generally only useful, if these branches don't need any other change for updating the ancestor. When they need than you need to work on the branch anyway and rebase other commits or add new ones on top, so you gain nothing compared to "rebase --onto" for each branch separately. If you don't have anything to update then that would be somewhat pointless to me. You can also just rebase them, when you sta…

Let's say you have this (modified from `git rebase --help`): ``` A---B---C main \ D---E---F feature1 \ \---G---H feature2 \ \---I---J feature3 ``` (sorry about the formatting here. I guess you'll have to copy & paste it to read it) What I'm saying is that if I want to fix something in D, I do `jj new D` to create a new commit on top of D. Then I make the fix, run tests, etc., and then I run `jj squash` to amend the c…

[deleted]

Re: Stacked Diffs with git rebase —onto

#172

Post by 1718627440 »

martinvonz wrote: post #169
1718627440 wrote: post #166

Earlier quoted context omitted.

I think this is generally only useful, if these branches don't need any other change for updating the ancestor. When they need than you need to work on the branch anyway and rebase other commits or add new ones on top, so you gain nothing compared to "rebase --onto" for each branch separately. If you don't have anything to update then that would be somewhat pointless to me. You can also just rebase them, when you sta…

Let's say you have this (modified from `git rebase --help`): ``` A---B---C main \ D---E---F feature1 \ \---G---H feature2 \ \---I---J feature3 ``` (sorry about the formatting here. I guess you'll have to copy & paste it to read it) What I'm saying is that if I want to fix something in D, I do `jj new D` to create a new commit on top of D. Then I make the fix, run tests, etc., and then I run `jj squash` to amend the c…

So what I am saying is that after you created D', it is true, that you need to run `rebase --onto` in git, while it is automatic in jj. But I think updating feature2 and feature3 is only really necessary to do now, when you want to change something in G-J also. If you don't and it wouldn't cause merge conflicts at all (logical and physical) then you could also just do this when you work on top of H or J the next time, so it wouldn't actually cause any more work in git compared to JJ.

--

The other thing I am saying is that I don't really let features depend on each other, I let them specify the API between them first and then develop them independently. Otherwise it is easy to violate boundaries. So the ideal is that any of G,H and I,J works with D,E,F and vice versa. Of course that is tangential and it doesn't always work that way.

Re: Stacked Diffs with git rebase —onto

#173

Post by lowboy »

qff wrote: post #150
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…

`jj` doesn’t allow temporary files in the repository that aren’t listed in `.gitignore`. This makes it unusable for me.

It does via snapshot.auto-track https://docs.jj-vcs.dev/latest/config/#paths-to-automaticall...

Re: Stacked Diffs with git rebase —onto

#174

Post by steveklabnik »

qff wrote: post #150
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…

`jj` doesn’t allow temporary files in the repository that aren’t listed in `.gitignore`. This makes it unusable for me.

There's multiple ways of handling this, depending on what you prefer.

Keeping these things in a private commit is one option.

Configuring auto-tracking to be off is another option.

Re: Stacked Diffs with git rebase —onto

#175

Post by steveklabnik »

yegle wrote: post #135
steveklabnik wrote: post #119

Earlier quoted context omitted.

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

Yeah, this is annoying right now. Someone is actively working on a patch to improve it, though.

Re: Stacked Diffs with git rebase —onto

#176

Post by steveklabnik »

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?

For me, that's probably jj undo, just because it makes everything else so nice to just give a try. I really don't worry about making mistakes.

But for me, it's not so much features that git doesn't have, it's that the core is factored in a way that's more focused and orthogonal. The stuff that I used to like to do with git is even easier and more straightforward with jj. This is more of the result of a bunch of different design decisions and how they fit together rather than just some specific feature that's great.

Re: Stacked Diffs with git rebase —onto

#177

Post by steveklabnik »

martinvonz wrote: post #169
1718627440 wrote: post #166

Earlier quoted context omitted.

I think this is generally only useful, if these branches don't need any other change for updating the ancestor. When they need than you need to work on the branch anyway and rebase other commits or add new ones on top, so you gain nothing compared to "rebase --onto" for each branch separately. If you don't have anything to update then that would be somewhat pointless to me. You can also just rebase them, when you sta…

Let's say you have this (modified from `git rebase --help`): ``` A---B---C main \ D---E---F feature1 \ \---G---H feature2 \ \---I---J feature3 ``` (sorry about the formatting here. I guess you'll have to copy & paste it to read it) What I'm saying is that if I want to fix something in D, I do `jj new D` to create a new commit on top of D. Then I make the fix, run tests, etc., and then I run `jj squash` to amend the c…

Hacker News doesn't support Markdown, but you can indent lines by two spaces to get it formatted like code: https://news.ycombinator.com/formatdoc

Re: Stacked Diffs with git rebase —onto

#178

Post by steveklabnik »

1718627440 wrote: post #168
martinvonz wrote: post #155

Earlier quoted context omitted.

The author of `git history` is a GitLab employee and prolific Git contributor. I think he knows how `git rebase` works.

I think the issue that wakawaka28 has and I also have is, that I don't think we should have lots of "wizards" for specific high-level operations users want to do. Then we will only end up with hundreds of commands, that all do slightly the same. Also it will train (new) users to complain about adding yet another command to do what they want, instead of letting them learn how to combine the already existing commands.…

For what it's worth, I mostly see jj as being to git what you describe in your first few paragraphs. That's why I like it so much.

Re: Stacked Diffs with git rebase —onto

#179

Post by _zoltan_ »

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've never heard of jj before this thread...

Re: Stacked Diffs with git rebase —onto

#180

Post by thunderfork »

glenjamin wrote: post #93
happytoexplain wrote: post #83

Earlier quoted context omitted.

This seems idealistic. It's very normal to be working on a feature that depends on a not-yet-merged feature.

I invite you to look into feature flagging. It is entirely viable to never have more than 1 or 2 open pull requests on any particular code repository, and to use continuous delivery practices to keep deploying small changes to production 1 at a time. That's exactly how I've worked for the past decade or so.

[dead]
Post reply on HN