Is there a jj tutorial not assuming git knowledge at all? I'd love to see how to approach jj without git.
Not really, but I think there should be.
I see a future in jj
121–130 of 336 posts
Re: I see a future in jj
#122Earlier quoted context omitted.
This is an interesting idea... jj has a templating language, but it's not stateful, so you couldn't like, hide some commits based on other commits, for example. But I'll file this away...
I've thought that it could be as simple as commit's with a message beginning with "minor:: " do not get shown by default.
Hmm, yeah that might work. I was thinking about grouping all “minor::” commits as one commit, but this sounds more feasible.
Re: I see a future in jj
#123> I also don’t mean to imply that everyone at Google is using jj, but the contingent feels significant to me, given how hard it is to introduce a new VCS inside a company of that size. I don't mean to imply that Google is fickle, but anything besides Google's perforce fork is deprecated every few years. We used to have a proper git wrapper, then mercurial+extensions, now jj is supposed to replace the mercurial thing,…
I don't think this is quite right.
The git wrapper was never fully supported and had some rough edges (I think it was only ever a 20% project, and also its, like, really old). And the customized mercurial has been around for more than 7 years, I think close to a decade (the client I'm using right now is turning 7, and it wasn't my first one).
Re: I see a future in jj
#124Does JJ have equivalet functionality to git's format-patch and am? Because I, for one, am rather fond of the e-mail based workflow and not having that would make JJ a no-go for me.
Re: I see a future in jj
#125Does it work with large binary files and not choke like git? Cause git may have won for webdev etc, but in some industries such as gamedev, Perforce is the king... git is barely used at all because it can't handle binary files worth a damn(yes I know about the large file extension, no it isn't sufficient).
Perforce’s binary support is basically equivalent to Git LFS, it does the same thing. What does Perforce binary support have that Git LFS doesn’t? AFAIK, the base issue that Perforce is already in use and it has enterprise support.
I am the last person to ever promote perforce, but as of last yearish it has the option for binary delta transfer using fastCDC.
Even without that, it is a just straight up a lot faster than git lfs. I know this because I benchmark it against git pretty frequently as I am creating my own large file capable VCS.
Re: I see a future in jj
#126Earlier quoted context omitted.
[flagged]
That line wasn’t even in the original post. It is not nearly the only technical advantage. The point of the post is just not about that topic, so that content is not in the post.
That line _is_ in the post. Search for it. I'm not sure what you're on about.
Re: I see a future in jj
#127Earlier quoted context omitted.
What I would love: - Everything locally stored in the repo: PRs, comments, issues, discussions, boards, ... - CLI first - Offline first (+ syncing) - A website for hosting/presentation
So you want Fossil?
When I tried Fossil it had things weirdly separated.
I was expecting when I make a commit, I would have the facility to specify what issues it addressed and it would close them for me automatically. It seemed there is so much opportunity there to "close the loop" when the issue tracker, etc and integrated in your VCS, but it wasn't taken.
Re: I see a future in jj
#128[flagged]
Found linus' alt
Re: I see a future in jj
#129> I also don’t mean to imply that everyone at Google is using jj, but the contingent feels significant to me, given how hard it is to introduce a new VCS inside a company of that size. I don't mean to imply that Google is fickle, but anything besides Google's perforce fork is deprecated every few years. We used to have a proper git wrapper, then mercurial+extensions, now jj is supposed to replace the mercurial thing,…
I don't think this is quite right. The git wrapper was never fully supported and had some rough edges (I think it was only ever a 20% project, and also its, like, really old). And the customized mercurial has been around for more than 7 years, I think close to a decade (the client I'm using right now is turning 7, and it wasn't my first one).
I started using git as my daily driver at Google in 2018. I was forcibly kicked off it for mercurial in 2020. The deprecation plan for mercurial is 2026 IIUC. Maybe if you adopted mercurial early it's different.
Re: I see a future in jj
#130I gave jj two honest tries. While first class conflicts is a cool idea, in practice I deal with staging/committing 30x more than conflict resolution, and coming from magit, using jj’s hunk split & select felt like being thrown into stone age. Plus I rebase a lot and get a lot of jj’s benefits from magit’s various rebase shortcuts already, IIRC first class conflicts was the only truly novel thing I didn’t have. For people like me who stage/commit often and judiciously I don’t think jj will beat magit until its hunk selection UX comes close.