But you still need to deal with a dirty working copy somehow. This blog post from today happens to describe one scenario where it's nice not to have to worry about changes in the working copy:
In some cases, yes, but I think the way jj handles conflicts is easier to follow. You can see the conflict resolution in `jj diff` and you can rebase it like a regular commit. rerere's state is harder to understand, I think. See https://github.com/martinvonz/jj/issues/175#issuecomment-107... for some more discussion.
This is slightly incorrect. I started it because I believed in the idea of modeling the working copy as a commit, but it's true that I made the storage pluggable from the beginning because I wanted to be able to convince my team at Google that we should use it internally too.
I thought it was simply a response to git5/git-multi getting deprecated once fig became popular.
I'm a bit surprised then, that's one of the things that has kept me from trying it as it feels weird to not have that much control over what gets into the commit. Using magit doesn't help as it's just way too good once you get used to it.
I would have spelled it "jiu-jitsu" if I had not looked up the spelling first and found that Wikipedia decided to spell it "jujutsu" (https://en.wikipedia.org/wiki/Jujutsu). Maybe I trusted Wikipedia too much; I have never practiced jujutsu/jiu-jitsu myself.
> JJ's conflict handling seems nice. Can't say that it's a big enough problem for me to qualify as a "major feature", but a seemingly nice improvement.
The advantages people first think of when they hear about jj's conflict handling are usually that you can collaborate on conflicts and that you can leave conflicts for later. What's less obvious [1] is that being able to store conflicts in commits means that we can always rebase descendants, so there are states like what Mercurial (and Sapling, I think) call "obsolete" and "orphan". There is also no "interrupted rebase" state when you're resolving conflicts.
These things simplify for the user. They also simplify a lot for developers. An example is how I spent about 2 weeks on a `hg amend --into` command for amending the changes in the working copy into an ancestor. I then implemented that in under an hour in jj. Much of the complexity in hg stemmed from dealing with the interrupted states while dealing with conflicts. (Other complexity in hg that jj doesn't have is dealing with a dirty working copy, dealing with concurrent operations, and simply complexity in the APIs for creating new commits in memory.)
[1] IIRC, it took me about a year after I added support for "first-class conflicts" until I figured out that it meant that we should simply always rebase descendants. Jujutsu had a orphans and a `jj evolve` command before then.
One simple example is undo. You can simply run `jj undo` if you made a mistake (it obviously won't unpush commits to a remote and such). You can go back as many steps as you like.
Jujutsu was started in late 2019. Got seems to have been started in late 2017. I have no idea why they didn't contribute to gitless instead of starting a new project.
reply