martinvonz

9 ms·

61.
by martinvonz 2y ago
You can try a different conflict marker style: https://jj-vcs.github.io/jj/latest/config/#conflict-marker-s...
62.
by martinvonz 2y ago
> I still don't understand the way jj handles conflicts. See https://jj-vcs.github.io/jj/latest/conflicts/ . > If I rebase and then fix a conflict later, are those conflict markers going to appear i
63.
by martinvonz 2y ago
The CLA may not be as bad as you think. There are different kinds of CLAs. This one does not give away your copyright at least. See https://github.com/jj-vcs/jj/discussions/4849 for discussion.
64.
by martinvonz 2y ago
I think the best way to answer most of your questions is just for you to try it yourself ( https://jj-vcs.github.io/jj/latest/install-and-setup/ ). > Everything is what? Not interactions affecting remotes (y
65.
by martinvonz 2y ago
When updating the working copy from one commit to another, I didn't think we would delete files that were not untracked in the first commit. I suspect the files are actually still available in the repo, but we'd appreciate a bug r
66.
by martinvonz 2y ago
You might find Unison interesting: https://www.unison-lang.org/docs/the-big-idea/
67.
by martinvonz 2y ago
Yes, I don't think anyone should worry that we're going to remove support for the storage system pretty much everyone uses (i.e Git).
68.
by martinvonz 2y ago
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: https://drewdevault.com/20
69.
by martinvonz 2y ago
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
70.
by martinvonz 2y ago
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 Goo
71.
by martinvonz 2y ago
Yes: https://martinvonz.github.io/jj/latest/git-compatibility/#co...
72.
by martinvonz 2y ago
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 Wikipedi
73.
by martinvonz 2y ago
> 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
74.
by martinvonz 2y ago
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.
75.
by martinvonz 2y ago
I don't think anyone has started working on it. We would want a design doc first. Note that the solution probably involve a local daemon process for caching reads and optimistically accepting writes and then sending them to the server
76.
by martinvonz 2y ago
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.
77.
by martinvonz 2y ago
Oh, I should also say that we have https://github.com/martinvonz/jj/issues/323 for your concern about automatically tracking files.
78.
by martinvonz 2y ago
I hope we'll be able to do better once we have an open-source storage backend that stores contents in a central database (like we do with Jujutsu at Google).
79.
by martinvonz 2y ago
This seems like a common misconception. The mention of the staging area in the README points to https://martinvonz.github.io/jj/latest/git-comparison/#the-i... . I'm guessing you didn't click that li
80.
by martinvonz 3y ago
Good point, we might want to document that. Btw, I've called it "native backend" and "native forge" myself, but maybe those are not the best terms because there are many possible native backends/forges. For ex
81.
by martinvonz 3y ago
Because Jujutsu is Git-compatible, there are lots of supported forges (GitHub, GitLab, etc.). There's no native forge yet.
82.
by martinvonz 3y ago
I would say that Mercurial has a simpler UX than Git without being less powerful. I think Jujutsu (see other posts here), which I started, also has simpler UX and is more powerful than Git in many ways. Have you looked at either of those?
83.
by martinvonz 3y ago
The current DVCS solution at Google is based on Mercurial, which is written in Python. Having worked on that for many years, I didn't want to write jj in Python. We've had problems with the performance of the current solution. Als
84.
by martinvonz 3y ago
To clarify, jj is not derived from Mercurial, but it's heavily inspired by it. The current DVCS solution at Google (called Fig) is based on Mercurial, however. But we're hoping to replace it by jj.
85.
by martinvonz 3y ago
I can't tell what the problem is based on that description. Feel free to file a bug report, or start a GitHub discussion, or ask on Discord.
86.
by martinvonz 3y ago
That's fair. Since 0.10.0 (~a month ago), there's support for immutable commits. See https://martinvonz.github.io/jj/v0.11.0/config/#set-of-immut... .
87.
by martinvonz 3y ago
If you want something you can use with existing git repos, there's also https://github.com/martinvonz/jj and https://sapling-scm.com/
88.
by martinvonz 3y ago
Jujutsu/jj ( https://github.com/martinvonz/jj ) keeps most of Git's data model and tries to improve the UX. It can even be used with existing Git repos.
89.
by martinvonz 3y ago
There's Jujutsu/jj: https://github.com/martinvonz/jj It can be used with regular Git repos.
90.
by martinvonz 3y ago
> Finally, Google is also moving away from Mercurial. Perhaps the JJ developers want to respond why (and check out Jujitsu -- it's a novel and very interesting system y'all should check out). Sure. I presented about that at Git

More ›