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

161–170 of 210 posts

Re: Stacked Diffs with git rebase —onto

#161

Post by martinvonz »

1718627440 wrote: post #160
tcoff91 wrote: post #115

Earlier quoted context omitted.

The UX around anonymous branches in git is not nearly as good as jj though. Also git has no equivalent to the operation log. `jj undo` and `jj op restore` are so sweet.

I can't comment on the UX of jj, but with git you literally just specify the commit, it doesn't feels tedious to me. > Also git has no equivalent to the operation log. For easy cases it's just git reset @{1}, but sure the oplog is a cool thing. I think it will be just added to git eventually, it can't be that hard.

You can specify a commit, yes, but how do you remember your set of unnamed commits? Once HEAD no longer points to a commit, it will not show up in `git log`.

I agree that Git could gain an operation log. I haven't thought much about it but it feels like it could be done in a backwards-compatible way. It sounds like a ton of work, though, especially if it's going to be a transition from having the current ref storage be the source of truth to making the operation log the source of truth.

Re: Stacked Diffs with git rebase —onto

#163

Post by martinvonz »

feelamee wrote: post #148
tcoff91 wrote: post #115

Earlier quoted context omitted.

The UX around anonymous branches in git is not nearly as good as jj though. Also git has no equivalent to the operation log. `jj undo` and `jj op restore` are so sweet.

isnt jj undo the equivalent of git reflog (+ reset/checkout)?

Mostly, yes. It also covers changes to the working copy (because jj automatically snapshots changes in the working copy). It's also much easier to use, especially when many refs were updated together. But, to be fair, it's kind of hard to update many refs at once with Git in the first place (there's `git rebase --update-refs` but not much else?), so undoing multiple ref-updates is not as relevant there.

Re: Stacked Diffs with git rebase —onto

#164

Post by oscillonoscope »

wild_egg wrote: post #138
steveklabnik wrote: post #132

Earlier quoted context omitted.

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.

You are mistaken. In the workflow I described, I am making changes on top of all branches at once and then deciding which branch to send the new commit to. This allows me to make changes simultaneously to both branches without friction.

Re: Stacked Diffs with git rebase —onto

#165

Post by 1718627440 »

martinvonz wrote: post #161
1718627440 wrote: post #160

Earlier quoted context omitted.

I can't comment on the UX of jj, but with git you literally just specify the commit, it doesn't feels tedious to me. > Also git has no equivalent to the operation log. For easy cases it's just git reset @{1}, but sure the oplog is a cool thing. I think it will be just added to git eventually, it can't be that hard.

You can specify a commit, yes, but how do you remember your set of unnamed commits? Once HEAD no longer points to a commit, it will not show up in `git log`. I agree that Git could gain an operation log. I haven't thought much about it but it feels like it could be done in a backwards-compatible way. It sounds like a ton of work, though, especially if it's going to be a transition from having the current ref storage…

The last one is always available via `git checkout -` and if you want to do more you can do `git checkout @{4}` etc. . It will also show up in `git log --reflog`. I honestly don't see the problem with naming things. Typing a chosen name is just so much more convenient than looking up the commit hash, even when you only need to type the unique prefix. When I don't want to think of a name yet, I just do "git tag a, b, c, ..."

I also tend to have the builtin GUI log equivalent (gitk) open. This has the behaviour, that no commit vanishes on refresh, even when it isn't on a branch anymore. To stop showing a commit you need to do a hard reload. This automatically puts the commit currently selected into the clipboard selection, so all you need to do is press Insert in the terminal.

> It sounds like a ton of work, though, especially if it's going to be a transition from having the current ref storage be the source of truth to making the operation log the source of truth.

I don't think that needs to be implemented like this. The only thing you need to do is recording the list of commands and program a resolver that outputs the inverse command of any given command.

Re: Stacked Diffs with git rebase —onto

#166

Post by 1718627440 »

martinvonz wrote: post #145
wakawaka28 wrote: post #143

Earlier quoted context omitted.

I don't think I would want to rewrite all branches based on rewriting one of the ancestors of those branches. This only makes sense for local branches, and I just never have such a set of branches. Most rebases are to get ahead of upstream work, and I can't rewrite that. The rest are to rewrite commits that I made, and I collapse all those commits down periodically anyway. In the rare case I might be able to use this…

> I don't think I would want to rewrite all branches based on rewriting one of the ancestors of those branches. This only makes sense for local branches, and I just never have such a set of branches. Yes, it's only meant for local branches. When I used Git, I had a script for rebasing dependent branches. I remember that a coworker had written a similar script. I think jj is generally more useful for people like me wh…

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 start working on the branch again or want to merge them.

--

For me branches also represent features, that should have clear boundaries, so when I work on one feature and that means, I need to rebase another one on top instead of being able to just merge them later, this indicates a spaghetti codebase where the interfaces between features are not properly defined and things depend on internals of other things.

Re: Stacked Diffs with git rebase —onto

#167

Post by tcoff91 »

1718627440 wrote: post #165
martinvonz wrote: post #161

Earlier quoted context omitted.

You can specify a commit, yes, but how do you remember your set of unnamed commits? Once HEAD no longer points to a commit, it will not show up in `git log`. I agree that Git could gain an operation log. I haven't thought much about it but it feels like it could be done in a backwards-compatible way. It sounds like a ton of work, though, especially if it's going to be a transition from having the current ref storage…

The last one is always available via `git checkout -` and if you want to do more you can do `git checkout @{4}` etc. . It will also show up in `git log --reflog`. I honestly don't see the problem with naming things. Typing a chosen name is just so much more convenient than looking up the commit hash, even when you only need to type the unique prefix. When I don't want to think of a name yet, I just do "git tag a, b,…

Yeah but in jj every time you run ‘jj log’ you see all your anonymous branches and you can rebase all of them at once onto main in 1 command.

When I’m exploring a problem I end up with complex tree of many anonymous branches as I try different solutions to a problem and they all show up in my jj log and it’s so easy to refer to them by stable change ids. Often I’ll like part of a solution but not another part so I split a change into 2 commits and branch off the part I like and try something else for the other part. This way of working is not nearly as frictionless with git. A lot of times I do not even bother with editor undo unless it’s just a small amount of undoing because I have this workflow.

Git is to jj like asm is to C: you can do it all with git that you can do with jj but it’s all a lot easier in jj.

Re: Stacked Diffs with git rebase —onto

#168

Post by 1718627440 »

martinvonz wrote: post #155
wakawaka28 wrote: post #154

Earlier quoted context omitted.

Well, if I had to guess, many current jj users are git veterans who are tired of watching git noobs struggle. The other segment is the git noobs themselves, who never really bothered to learn git and have a deep aversion to reading the manual and doing basic experiments. Just a guess, though. I think I saw Scott Chacon talk about his git config file and advanced git features. Whoever it was, it mentioned GitButler. T…

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.

What we should do instead is provide a bunch of primitives, that as high-level are as possible so to not end up with duplicate commands, which is what git does currently. `git history` as a name is somewhat pointless, since the whole point of git is to produce and modify the history. In that sense `git history` already exists, it is called `git`.

I think the issue newbies have is not that git commands are hard per se, but that they don't think in terms of modifying the graph yet, or that they don't know which primitives are available.

Re: Stacked Diffs with git rebase —onto

#169

Post by martinvonz »

1718627440 wrote: post #166
martinvonz wrote: post #145

Earlier quoted context omitted.

> I don't think I would want to rewrite all branches based on rewriting one of the ancestors of those branches. This only makes sense for local branches, and I just never have such a set of branches. Yes, it's only meant for local branches. When I used Git, I had a script for rebasing dependent branches. I remember that a coworker had written a similar script. I think jj is generally more useful for people like me wh…

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 changes into D. The descendant commits (E through J) then get automatically rebased and the feature bookmarks/branches get updated.

I didn't follow what you about it other changes needed for updating the ancestor. Can you explain in the context of this example?

Re: Stacked Diffs with git rebase —onto

#170

Post by 1718627440 »

tcoff91 wrote: post #167
1718627440 wrote: post #165

Earlier quoted context omitted.

The last one is always available via `git checkout -` and if you want to do more you can do `git checkout @{4}` etc. . It will also show up in `git log --reflog`. I honestly don't see the problem with naming things. Typing a chosen name is just so much more convenient than looking up the commit hash, even when you only need to type the unique prefix. When I don't want to think of a name yet, I just do "git tag a, b,…

Yeah but in jj every time you run ‘jj log’ you see all your anonymous branches and you can rebase all of them at once onto main in 1 command. When I’m exploring a problem I end up with complex tree of many anonymous branches as I try different solutions to a problem and they all show up in my jj log and it’s so easy to refer to them by stable change ids. Often I’ll like part of a solution but not another part so I sp…

I guess I never had complex trees from such an action, just a bunch of parallel branches, but I would say splitting and picking commits from different branches is not exactly hard with git either. Also you can also see them in git, but they won't have change ids of course.
Post reply on HN