Hard part is keeping the feature branches orthogonal and maintaing all the -base branches. Every fixup commit would invalidate them.
Stacked Diffs with git rebase —onto
201–210 of 210 posts
Re: Stacked Diffs with git rebase —onto
#202Earlier quoted context omitted.
Sounds like jj just simplifies the interface of some git commands, mainly. After talking to some jj enthusiasts here, I think we just have a different perspective about what needs to be simple and even what constitutes simple. There is probably some lingering unfamiliarity with git among jj enthusiasts as well. I don't want to teach git to people who are not programmers, but I wouldn't want to teach any programmer's…
> There is probably some lingering unfamiliarity with git among jj enthusiasts as well. I've heard this a few times. But from what I've seen, it seems like often it's the Git enthusiasts who seem to be unfamiliar with jj. I haven't heard from anyone who used jj for a few months and knew it well and then switched to Git.
I have never used jj, nor met anyone who used it in person. Given how new it is, you just won't find enough people who used it at all. I think git is like the vim of VCS systems and like vim there are some people who just don't think that way. I think jj might be more like emacs in that it has the initial appearance of being simple, but when you get into it more deeply you realize that it is not so simple after all.
I have used other VCS systems that made similar claims about being simpler, such as Mercurial. I think I got to be fairly expert at Mercurial before becoming expert at git, and even used it to interact with SVN repositories. (I've also used git for SVN. This is another thing git does better.) After actually learning git past the first few commands, I would never go back to Mercurial. I don't want to mix and match systems either. There are things I want git to do better, but I would not call these simple feature requests... They are more along the lines of advanced features that need to be extended or polished.
Re: Stacked Diffs with git rebase —onto
#203Earlier quoted context omitted.
Amending a commit behind HEAD is not a simple thing in general. You can have conflicts. When it can be done simply, it can be done in 2 steps with git (or less than 2, since you can amend lots of commits with one rebase). What are the 2 steps? After adding what you want, here they are: - `git commit --fixup HEAD~3` - `git rebase --autosquash HEAD~4` The "less than 2 steps" part comes from fixing up more than one comm…
Maybe you know this already but it's `jj squash --into @----` whether there are conflicts or not.
I didn't know that, but I'm not surprised that this is possible because jj allows you to defer conflict resolution. I for one prefer git's step-by-step rebase model that makes you address conflicts at the time of the rebase. If you aren't ready to address conflicts, you shouldn't be mucking around with the commit history yet. Also, if you turn on rerere, then you can also (usually) avoid fixing the same conflicts multiple times.
Re: Stacked Diffs with git rebase —onto
#204Earlier quoted context omitted.
Add `--update-refs` to your interactive rebase and it will give you an easy line to know how many commits to drop because it will add an `update-ref` line for the old branch. You can just easily delete everything up to and including that `update-ref` line and don't have to manually pull up a git log of the other branch to remember which commits already merged. (Plus, of course, if you have multiple branches stacked,…
Nice; thanks :) I usually squash-merge. Does that break this workflow?
Depends on how fast you delete merged branches?
I picked up `--update-refs` to not lose my mind working in squash merge repos. I much prefer merge commits. I often make good, well documented commits and I like having access to the original commits if I need them, so when in a squash merge repo I become a branch hoarder renaming merged branches with a `zoo/` prefix (to drop them low in sort order, among other reasons it is name `zoo/`).
I will often keep experiment branches around and `--update-refs` helps me manage that because if I see commits that might update-ref a `zoo/` branch I know to drop them from the experiment branch.
All of that discovery of already merged commits would be automatic/cheap in rebases with merge commits. I was very frustrated before discovering `--update-refs`. I'm still often frustrated with squash merging, but keeping a large `zoo/` and having `--update-refs` is extra work that almost replicates the experience of just using merge commits in the first place. I don't know why so many think squash merge workflows are "simpler".
Re: Stacked Diffs with git rebase —onto
#205Earlier quoted context omitted.
jj doesn't force you to resolve the conflicts immediately, so it'll just show that they're conflicted until you decide you want to go fix them.
That sounds real painful and confusing. You could end up with a bunch of conflicts in separate commits, on multiple branches, none of which you actually wanted to modify in the first place.
It’s not any different than git, the only difference is that you can choose to resolve the conflict when you want, instead of it interrupting rebase.
If you don’t want to modify a branch, then you shouldn’t rebase it, same as git.
Re: Stacked Diffs with git rebase —onto
#206Earlier quoted context omitted.
I have one and a half decades of muscle memory burned in with inoremap jj `^ It's not something I can just shift away from.
Definitely let your keybinding keep you from trying out and using a fantastic tool.
I already use Graphite today on top of git. Others are using alternatives like Sapling, etc.
To go back to your question around why people still use these workarounds on top of git, it's because the CLI is just one piece of it. With Graphite, I also get a stack-aware merge queue and review dashboard.
Re: Stacked Diffs with git rebase —onto
#207Earlier quoted context omitted.
That sounds real painful and confusing. You could end up with a bunch of conflicts in separate commits, on multiple branches, none of which you actually wanted to modify in the first place.
It’s not any different than git, the only difference is that you can choose to resolve the conflict when you want, instead of it interrupting rebase. If you don’t want to modify a branch, then you shouldn’t rebase it, same as git.
Someone just told me that if you rewrite a commit that is an ancestor of multiple branches, it will (or can) automatically rewrite all the branches.
What does it even mean to not resolve conflicts? Your branch code and/or history is broken until you come around and fix it? If so, forcing you to fix it immediately is better. Aside from the practical implications of deferring conflict resolution, I just can't think of a reason I would do it in the first place. If a branch can't be rebased with zero work, and I don't have time to do that work, I just don't do the rebase.
Re: Stacked Diffs with git rebase —onto
#208Earlier quoted context omitted.
It’s not any different than git, the only difference is that you can choose to resolve the conflict when you want, instead of it interrupting rebase. If you don’t want to modify a branch, then you shouldn’t rebase it, same as git.
Someone just told me that if you rewrite a commit that is an ancestor of multiple branches, it will (or can) automatically rewrite all the branches. What does it even mean to not resolve conflicts? Your branch code and/or history is broken until you come around and fix it? If so, forcing you to fix it immediately is better. Aside from the practical implications of deferring conflict resolution, I just can't think of…
Sure, my point is just that if you don’t want history re-written, you just don’t re-write it. If you have multiple descendant branches and for some reason you don’t want the children to move as well, you can move them back. It’s almost the opposite of what the article describes; instead of needing to choose to move children, children move automatically and you move ones you don’t want to back. I’ve never wanted to do this but if it happened it would be easy enough to fix.
It looks like this: when a git rebase would pause the rebase to make your resolve a conflict, jj keeps going. When the rebase finishes, if there are any conflicts, they’re displayed in the log with ?? after their ID. jj won’t let you push a branch with conflicts until the conflict is resolved. You can fix the conflict by either editing that commit directly, or my preferred way, which is to make a new change on top and then squash the resolution back in after you read it over.
So there’s a few thins about why this is useful: because children are also rebased, you can see immediately how much work, if any, you have to do. I have an alias to rebase all open branches on top of trunk, and will often pull trunk, run it, and see if I have any work to do to update them. “Oh, only one of my three branches needs work, I’ll work on the two that are fine first” can happen, and that third can just sit there. Or, as I said before, I could move it back on top of its old base, and the conflict disappears. Or, say I suspected none of them conflict, but all three do, and I don’t want to do it at all right this moment, I’ll just jj undo and they’re all unconflicted and back in place.
Re: Stacked Diffs with git rebase —onto
#209Earlier quoted context omitted.
This isn't going to be a very HN-like comment. But it's rooted in fact: That is complete nonsense.
Lol you could just say you disagree. Is it SO alien to you that users of the most popular VCS in the world might like it the way it is? After arguing with you guys, the only deep fact coming through is that people like you get irrationally optimistic about new tools, after the old favorite doesn't appeal to you for some reason.
Yeah your parent is being combative all over this thread, there’s just no reason for it.
For whatever it’s worth, the general stance of the project and most of the community is “git is good, we like jj more, but you should use whatever you prefer.” Lots of us loved git before jj came along, and there’s a lot of cross pollination between the two projects. I hope your parent takes the feedback and chills out.
Re: Stacked Diffs with git rebase —onto
#210Earlier quoted context omitted.
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.
Pragmatic is using the best tool for the job. Certainly subjectively, and arguably objectively, jj is the better tool in many ways. My advice is to try it. You should like it, if you're in the majority of folks to give it a sincere shot. If you don't like it, cool. But then my advice changes. jj is probably the future. Adapt or become one of those old-timers who froze their learning in time.
Pragmatic is not bothering to switch to the shiny new thing just because it's shiny and new if your current tool doesn't give you any problems.