341–350 of 517 posts
Does jj have partial clones of remote repo?
jj does not have partial clones, but it does have sparse checkouts.
Sparse checkouts from remote repo directly or do I need to clone it in whole locally and only then can do a sparse checkouts into some work directory?
Earlier quoted context omitted.
Submodules work fine but yeah, it's frustrating that lfs is taking so long. But there seems to be some momentum recently https://github.com/jj-vcs/jj/pull/9068
The git compatibility page states that submodules are not supported https://docs.jj-vcs.dev/latest/git-compatibility/
This is sort of similar to how you can create lightweight tags with jj tag, but you need to push them with git push --tags.
Earlier quoted context omitted.
A couple things off the top of my head: - You aren't forced to resolve rebase/merge conflicts immediately. You can switch branches halfway through resolving conflicts and then come back later and pick up where you left off. You can also just ignore the conflicts and continue editing files on the conflicted branch and then resolve the conflicts later. - Manipulating commits is super easy (especially with jjui). I reor…
> So anything that would be destructive in git (e.g. rebase, pull, squash, etc) can be undone. It’s possible to recover from these with git reflog, though.
I've used jj for only a year, and have used "jj undo" countless times.
There's a huge benefit to having a simpler mental model.
Earlier quoted context omitted.
>There is also `jj git clone`, `jj git fetch`, `jj git push`, etc. If the compatibility isn’t automatic… why would I bother with jj commands here at all? “Git with extra steps”
The on-disk repository compatibility is automatic. But if you're trying to fetch something via a specific protocol, you use the command for the protocol you want to use. There is no extra step between `git push` and `jj git push`, they're both one step.
The issue is pretty obvious to me. GIT is the standard and that likely won’t change for some time. So if jj makes my git life better, awesome, but it’s just a wrapper and I need to know all the git voodoo now with jj voodoo on top, I don’t quite get it.
Is there a concise introduction / overview of jj? I've read 8 pages of this link and the author is still in preambles and considerations... Not my favourite style of article!
You have a DAG of "changes" to the repo state. Each change has a stable ID, you can modify its contents or description without changing the ID. There's always a "current" change checked out, JJ automatically snapshots your edits to files into this change. JJ provides tools to edit changes, describe them, group them into named branches (bookmarks), reorder them, split them apart, etc. JJ defaults to being backed by gi…
With jj you have to fetch, start new space off a bookmark, edit code, commit it, update the bookmark and finally push?
I'm giving jj a try but one aspect of it I dislike is edits to files are automatically committed, so you need to defensively create empty new commits for your changes. As in, want to browse the repo from a commit 2 weeks ago? Well if you just checkout that commit and then edit a file, you've automatically changed that commit in your repo and rebased everything after it on top of your new changes. So instead you creat…
You can disable the auto staging of new files since recently which removed the main grype for me
Earlier quoted context omitted.
think of jj like, I want to build xyz, ``` jj desc -m "feat: x y & z" ``` do the work. ``` jj split ``` Split up the parts and files that you want to be separate and name them. This will also allow you to rename stuff. ``` jj bookmark create worklabel-1 -r rev1 jj bookmark create worklabel-2 -r rev2 # Push both commits # since we just split them they are likely not inter-dependent # so you can rebase them both to bas…
I am dumb. why is that better than a git branch or a git worktree ?
This tool was described perfectly the other day. JJ is the Dvorak of Git. Most people could careless about Dvorak layout, 99.8% of people use qwerty just fine. Those 0.02% though, they're loud, and they want everyone to know how great the reinvention of bread is.
Earlier quoted context omitted.
I guess that makes sense but also reinforces the confusion I have on whether jj is just another git "porcelain" (aka UI), or a replacement for git altogether. If it aims to mainly improve the UX (do the same things you were doing before but easier), then it's irrelevant to those of us who have been lucky to find and learn sensible UXs. If it aims to be a git replacement, I'm a little curious why the developers would…
> then it's irrelevant to those of us who have been lucky to find and learn sensible UXs Only if you're a solo dev that doesn't work on a team or have to mentor new devs that haven't developed good intuitions for this. This strikes me a lot like the C vs. safer programming language debate all over again.
> This strikes me a lot like the C vs. safer programming language debate all over again.
I don't see how. Safer programming language address a clear problem in C, with trade-offs (sometimes arguably the trade-offs may not be worth it, and in my experience that's what the debate tends to be about). If jj is a replacement for git it should be clear what problem within git it aims at addressing. If the problem is in the UX, then to me and many others it's not worth the trouble.
Earlier quoted context omitted.
For me, it wasn't so much that jj enabled things I couldn't do before, though there are some things. What it enabled was me doing the things I was doing, but in a more easy way. This also leads you to do things that you can do, but sometimes avoid because it's a lot of work.
I guess that makes sense but also reinforces the confusion I have on whether jj is just another git "porcelain" (aka UI), or a replacement for git altogether. If it aims to mainly improve the UX (do the same things you were doing before but easier), then it's irrelevant to those of us who have been lucky to find and learn sensible UXs. If it aims to be a git replacement, I'm a little curious why the developers would…
> then it's irrelevant to those of us who have been lucky to find and learn sensible UXs.
I was never someone who was upset at git's UX. I never found the 'hg is so much nicer' thing compelling. But then, I found that jj is just so much nicer to use, for me, that I haven't used git itself in years at this point. But it's also true that if you like using git, and want to keep using it, that's fine! The wonderful thing about the interop here is that I can use jj, and you can use git, and we're all good.
> I'm a little curious why the developers would decide to re-implement something from scratch only to end up with an "alternative" that is mostly compatible
Realistically, with git's dominance, compatibility is the only way that you get people to actually try out your thing. I know I wouldn't have given it a shot unless I could use it with a git repo.
> or add new features
I mean, there's two things here: one of which is, jj does have new features. I described the ability for a jj repo to exist in a conflicted state upthread, for example. jj undo is a godsend. But at the same time, at the end of the day, when you're trying to manipulate a graph of changes, there's always some way to end up in the same end state with git, because, well, you're trying to interoperate. So you can sort of handwave away a lot of features with a kind of "well I can do that in git via ", and sure, that's true in a sense, but tools affect the way you work. I'm much more effective with jj's model of the world than I was with git's, even though I didn't actively feel that pain until I tried jj.
> It really wasn't until I learned magit
Ah, you use magit! So yeah, like, jj is like magit in the sense that it lets you interact with a git repository in a different way than the standard tool. And that's useful. I never would have used magit because I don't use emacs. (and there are some folks trying to do "magit but for jj"...)
> But the way git works internally seems pretty great to me. Too often, criticism of git conflates the two.
I agree, in general. I do think that there are still good criticisms to be made, but a lot of it is uninformed. Just how things go.
Earlier quoted context omitted.
You can disable the auto staging of new files since recently which removed the main grype for me
ooo that will be a nice improvement. So many times I've run `jj status`, then saw a file I wanted gitignored, so I'll edit my gitignore, but the file has already been added to the repo so I have to `mv /tmp/ && jj status && mv /tmp/ .` to get the file out of the repo.