martinvonz

12 ms·

91.
by martinvonz 3y ago
See https://github.com/martinvonz/jj for a VCS that's compatible with Git and has a simpler CLI with undo functionality and first-class conflicts (you can rebase conflict resolutions, for example). It's what
92.
by martinvonz 4y ago
Other similar projects are https://github.com/arxanas/git-branchless and https://github.com/martinvonz/jj .
93.
by martinvonz 4y ago
No, the CLI prevents that because the remote is unlikely to know how to interpret conflicts. In a future where the remote understands conflicts, then you'll be able to push conflicts to a remote and collaborate on the conflict resoluti
94.
by martinvonz 4y ago
I think the more important thing is that jj (and hg and git) don't use the AST at all, at least not yet. Does Pijul?
95.
by martinvonz 4y ago
Oh, in the context of Sapling, I should say that Jujutsu runs the equivalent of `sl restack` after every command. Thanks to first-class conflicts, that always works.
96.
by martinvonz 4y ago
I think those two things that arxanas mentioned are the biggest differences (i.e. working-copy-as-commit and conflicts in commits). I haven't used Sapling, but I suspect Jujutsu has better support for moving commits (and parts of commi
97.
by martinvonz 4y ago
I think it would be better for this post to link to https://github.com/Byron/gitoxide
98.
by martinvonz 4y ago
For people who want Git's data model but a better CLI, check out https://github.com/martinvonz/jj . It's a more Mercurial-like CLI but you can use it with existing Git repos. It also includes undo functionalit
99.
by martinvonz 4y ago
> I honestly can't see how git could be easier given the requirments of the tool. If you're curious how it can be done (IMO), take a look at https://github.com/martinvonz/jj . It's its own VCS but als
100.
by martinvonz 4y ago
If the other SCM is compatible with Git, you may not have to learn much about Git. That's my hope for my SCM: https://github.com/martinvonz/jj . I agree that it seems very hard for a new SCM to get many users witho
101.
by martinvonz 5y ago
Check out https://github.com/arxanas/git-branchless for `git undo` (and more)! (arxanas shared a link to my project elsewhere in this thread :))
102.
by martinvonz 5y ago
Sturdy (getsturdy.com) seems to be another solution in the same space, right?
103.
by martinvonz 5y ago
Does https://github.com/martinvonz/jj/blob/main/docs/git-comparis... help explain?
104.
by martinvonz 5y ago
That gist seems like a simplified version of https://github.com/mhagger/git-imerge , so check that out if you haven't. (I haven't looked at git-imerge in a long time, so I should read about it again myself.)
105.
by martinvonz 5y ago
I hope to one day make it better, but it's very low priority right now because the Git backend works well and has the big advantage that it's compatible with Git :) Also see https://news.ycombinator.com/item?id=304
106.
by martinvonz 5y ago
Good question. You're right on both guesses. One reason is that I want to make sure the API works well enough that it's easy to replace the backend. The current native backend is called `local_store` because it stores files locall
107.
by martinvonz 5y ago
FYI, there was an update on that issue saying that they're going to create an overlay tomorrow.
108.
by martinvonz 5y ago
I don't think skrebbel was saying that the branches are not git-compatible, I think they were just wondering if there is support for branches at all, but I'm not sure. Anyway, there is support for branches. They behave more like
109.
by martinvonz 5y ago
Yes, they are supported, and documented at https://github.com/martinvonz/jj/blob/main/docs/branches.md . I need to document better how to use them for common workflows like GitHub PRs. FYI, here&#x27
110.
by martinvonz 5y ago
Yep. Same thing in Jujutsu (the recursive merge is at https://github.com/martinvonz/jj/blob/a6ef792ba66b5b19e75282... ). Probably the biggest difference compared Git there is that it'll still work even i
111.
by martinvonz 5y ago
I filed https://github.com/martinvonz/jj/issues/61 about having Nix packages. I should learn about Nix packaging some day, but I'd appreciate any help I can get.
112.
by martinvonz 5y ago
I'm not sure if I'm allowed to say whether Piper has those features, but since you seem to be a Googler, you probably know (or can find out) :) I suppose I can still tell you that the features were not inspired by Piper without
113.
by martinvonz 5y ago
Yes and no. For example, if you reorder two commits, the new child commit will never have conflicts even if the parent had conflicts. That's because the changes from both original commits still apply afterwards. Similarly, if you rebas
114.
by martinvonz 5y ago
These are representations of conflicts that are stored as special files, they are not regular files with conflict markers in. If you look at the commit with regular `git`, you're going to see a weird file with some JSON in it.
115.
by martinvonz 5y ago
Yes, no staging area. Does https://github.com/martinvonz/jj/blob/main/docs/git-comparis... help address your concern?
116.
by martinvonz 5y ago
No, there's no particular support for large files yet.
117.
by martinvonz 5y ago
I doesn't work very well yet. See https://news.ycombinator.com/item?id=30399554 .
118.
by martinvonz 5y ago
> You cover `git add -p`, but I want `git add -e`. Interesting. I don't think I've heard anyone use `git add -e` before. It should be easy to add that feature, but it would be very low priority since so few users seem to like t
119.
by martinvonz 5y ago
> 1) What are the advantages of using native backend as compared to git? Very few. The disadvantages are generally much larger. The main advantage is that you won't run into a (harmless) race that happens once in a while with the gi
120.
by martinvonz 5y ago
> I realized that this may not play nice-nice with jj's commit-everything model Yes, I suppose you might not want to sign every working copy commit, but as you noted on the issue, it would probably make sense on `jj close/commi

More ›