Live data from Hacker News

Jujutsu Megamerges and jj Absorb

v5.chriskrycho.com

51–60 of 66 posts

Re: Jujutsu Megamerges and jj Absorb

#51
post #48

Earlier quoted context omitted.

The difference between git and svn is, svn is very fixed in terms of workflow. On the other hand, git allows many different workflows, and allows people to handle their codebases the way they see fit. Of course, no tool is truly universal, and git frontends and alternatives leverage different parts of the underlying data structures with different trade-offs. I personally never use rebase, and am a merge guy. I don't…

> I personally never use rebase Probably a lot of that is because it is painful. When it becomes a no-op, suddenly a lot of things become easy to do. Do you ever want to go back and edit a previous unpublished commit? Yes fixups exist, but that’s a band aid over the fact that editing a previous one is annoying and hard. Do you ever want to maintain a linear chain of branches? Branch A needs to be merged before Branch…

> Do you ever want to go back and edit a previous unpublished commit? Yes fixups exist, but that’s a band aid over the fact that editing a previous one is annoying and hard.

Also unnecessary, "git rebase -i" has an "edit" command that pauses the rebase at that commit to let you do whatever.

Re: Jujutsu Megamerges and jj Absorb

#52

Does jj do anything about submodules being horribly buggy in Git, or LFS being taped on the side as an afterthought? I guess they can fix the submodule bugs but presumably they can't fix LFS without breaking Git compatibility?

Right now Jj basically ignores submodules, they do want to fix it but haven’t yet. So you just use git commands in a colocated repo for now. Large file stuff is also a “want to do something better but no progress yet” kind of thing.

I think having both those working would be a serious reason for a lot of people to switch. E.g. just having working submodules and worktrees would do it for me.

Fingers crossed. Glad we're finally getting some viable Git competition with jj, Sapling and Pijul.

Re: Jujutsu Megamerges and jj Absorb

#53

Earlier quoted context omitted.

Right now Jj basically ignores submodules, they do want to fix it but haven’t yet. So you just use git commands in a colocated repo for now. Large file stuff is also a “want to do something better but no progress yet” kind of thing.

I think having both those working would be a serious reason for a lot of people to switch. E.g. just having working submodules and worktrees would do it for me. Fingers crossed. Glad we're finally getting some viable Git competition with jj, Sapling and Pijul.

To be clear, submodules work, you just have to use the git commands to update them. I agree things will be nicer when that’s not necessary though :)

Re: Jujutsu Megamerges and jj Absorb

#54
post #51
post #48

Earlier quoted context omitted.

> I personally never use rebase Probably a lot of that is because it is painful. When it becomes a no-op, suddenly a lot of things become easy to do. Do you ever want to go back and edit a previous unpublished commit? Yes fixups exist, but that’s a band aid over the fact that editing a previous one is annoying and hard. Do you ever want to maintain a linear chain of branches? Branch A needs to be merged before Branch…

> Do you ever want to go back and edit a previous unpublished commit? Yes fixups exist, but that’s a band aid over the fact that editing a previous one is annoying and hard. Also unnecessary, "git rebase -i" has an "edit" command that pauses the rebase at that commit to let you do whatever.

This is roughly the reaction I meant going into this discussion :)

The rebase next level part is not about using git rebase in the right way, it's about every command including status sometimes doing 15 rebases without even mentioning it.

Re: Jujutsu Megamerges and jj Absorb

#55
post #51
post #48

Earlier quoted context omitted.

> I personally never use rebase Probably a lot of that is because it is painful. When it becomes a no-op, suddenly a lot of things become easy to do. Do you ever want to go back and edit a previous unpublished commit? Yes fixups exist, but that’s a band aid over the fact that editing a previous one is annoying and hard. Do you ever want to maintain a linear chain of branches? Branch A needs to be merged before Branch…

> Do you ever want to go back and edit a previous unpublished commit? Yes fixups exist, but that’s a band aid over the fact that editing a previous one is annoying and hard. Also unnecessary, "git rebase -i" has an "edit" command that pauses the rebase at that commit to let you do whatever.

What jj does is not require you to pause. It’s fine with leaving stuff in a conflicted state, letting you do whatever you want as a next step. That may be resolving the rebase, but maybe you didn’t realize you were gonna have a conflict and want to get something else done real quickly.

In-memory, always succeeding rebases are just really nice.

Re: Jujutsu Megamerges and jj Absorb

#56
post #13

Earlier quoted context omitted.

Just try it! I converted 6mo ago after finally pulling together the motivation to give it a shot. My biggest hesitation was in how long I expected to struggle with it before feeling comfortable, followed closely by skepticism about how good the compatibility story actually is. Both, it turns out, were non issues. It took all of a day to feel perfectly comfortable using it. I spent the rest of the week gradually plugg…

How's the tool compatibility when using gg tho? My repo work tends to be split between git and magit, and while I would very much welcome the ability to get rid of git for a better experience, doing so at the cost of magit is an extremely steep hurdle.

[deleted]

Re: Jujutsu Megamerges and jj Absorb

#58

Earlier quoted context omitted.

Right now Jj basically ignores submodules, they do want to fix it but haven’t yet. So you just use git commands in a colocated repo for now. Large file stuff is also a “want to do something better but no progress yet” kind of thing.

I think having both those working would be a serious reason for a lot of people to switch. E.g. just having working submodules and worktrees would do it for me. Fingers crossed. Glad we're finally getting some viable Git competition with jj, Sapling and Pijul.

It does not implement Git worktrees, but instead implements its own notion of workspaces which frankly I find much nicer (unsurprisingly!). As with most things jj: just as much or more power than Git, but less hassle.

Working with submodules natively (see steveklabnik’s sibling comment for the “non-native” bit) will definitely be a big win.

Re: Jujutsu Megamerges and jj Absorb

#59
It's a bit a joke, but not too much: the next step will be full integration with editor's undo/redo mechanism, which in the end could be seen as a log-based storage. Because that's the trend I've seen on the (little) new ideas from the VCS world.

Re: Jujutsu Megamerges and jj Absorb

#60
post #46

Earlier quoted context omitted.

> this isn't something they'd ever need anyways. Oh I do that quite often, either because I didn’t realise I was committing on the wrong branch, or I decided to split my work in two branches, or i need some other unmerited change for my current branch… It’s usually a rebase —onto or cherry-pick, I’d say I agree it’s not simple. jj seems interesting, I’m very comfortable with git but I think its UX is terrible, but ev…

Nobody else needs to convert to jj for you to use it, so there’s no real downside to switching.

Yeah, this is the real advantage that jj (and sapling) have compared to how many years I'd been hearing about fossil and seeing it as a non-starter to experiment with.
Post reply on HN