Live data from Hacker News

Jujutsu: A Git-compatible DVCS that is both simple and powerful

github.com

201–210 of 269 posts

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#201
post #162

Earlier quoted context omitted.

One can still use Subversion to store binary files in VCS...

Nexus, Artifactory, Packages (deb, rpm, nix), Cache, GitHub Releases... There are so many places you can grab a signed binary from that are just outright better for the health of your repo, and will respect your developers time.

The issue is not limited to archives, artifacts, and packaging. Game projects, for example, have large directories with many binary assets which need to be change-controlled. Artifact repositories address distribution, in a way, but don't generally support change control much if at all.

(And yeah, git's historically a poor choice for this – so you may see companies sticking with Perforce or other non-distributed solutions.)

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#202
post #197

what's the advantage of native backend compared to git repo backend?

> At this time, there's practically no reason to use the native backend. The backend exists mainly to make sure that it's possible to eventually add functionality that cannot easily be added to the Git backend.

From the README, no advantage for now.

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#203
post #120

I haven't really used git on the command line for years now, except for some special cases. In my daily usage, I rely on the built-in IDE integration (IntelliJ, FWIW), and I don't understand why anyone would put up with doing it manually. I can do partial commits by selecting individual lines right in my editor. I can view all branches, merge them, cherry-pick from them, commit stuff or amend it, pull updates, edit t…

A lot of people who are starting out using git don’t understand how git works (what a commit is, what a branch is, what you can do to them). And they start to blame the CLI tool and start to hope that using the GitHub Desktop app will make everything make sense. This is the most common context where people say “you have to learn the git CLI.”

(Here’s an example from a few days ago from someone who proposes using GitHub Desktop in order to avoid learning git commands: https://www.reddit.com/r/learnprogramming/comments/15b7pra/s...)

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#204

Earlier quoted context omitted.

How about why not? The only reason it's not done is because git doesn't support it.

This isn't true at all. We were storing binary files separately via Maven for Java projects for almost 20 years now. This was done with SVN projects. Keeping the blobs out of your source repos has been the preferred way for a long time. [Edit] The only folks who seem to want to do this are game developers, and they are generally not people you would want to emulate.

Then how come git-lfs even exists at all? There's clearly a demand for it. Whether it's good practice is up for debate.

> Keeping the blobs out of your source repos has been the preferred way for a long time.

This is just appeal to tradition.

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#205
post #120

I haven't really used git on the command line for years now, except for some special cases. In my daily usage, I rely on the built-in IDE integration (IntelliJ, FWIW), and I don't understand why anyone would put up with doing it manually. I can do partial commits by selecting individual lines right in my editor. I can view all branches, merge them, cherry-pick from them, commit stuff or amend it, pull updates, edit t…

I have realized I have 15 years of git experience (incredible if true) and just got really, really used to it. Still excited if jj is a good follow-up since it sounds like it's not too far away from git's model.

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#206
post #78

Earlier quoted context omitted.

> There should be a .local.gitignore to somesuch I think .git/info/exclude is what you're looking for? (and also the global ~/.config/git/ignore)

I've used that file before but... it always felt sort of hacky. And every time I want to use it, I need to figure out where it is. It really feels like there should be a more obvious, straight forward way to do it. Admittedly, "user friendly" is not git's strong suit.

The .git directory seems like the obvious location for it; I agree that info/exclude isn't the most obvious path (I had to look up what the exact path was again for my previous comment), but all things considered that seems like a minor issue. I suppose you could symlink .git/ignore to .git/info/exclude or something in the git template.

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#207
post #196

Does anyone have experience with large repo's of say, 100 GB? Does jj incur performance penalty's compared to native git?

It depends on whether you're talking about 100 GB repository size or working copy size.

- Currently no partial/shallow clones, so you need to materialize the entire repo on disk.

- Working copy status can take a while (see https://github.com/martinvonz/jj/issues/1841 for tracking issue). This can be ameliorated at present by configuring Watchman as a filesystem monitor, and work is underway to improve status further.

- No support for Git LFS at present (even in colocated repos). When using the Git backend with jj, you would expect the same problems with regards to large file management.

- I haven't noticed any particular performance issues when interacting with the object store a large repository. It should be approximately the same as for Git since it uses libgit2 for the Git backend.

- Faster for operations that can be done in-memory in jj but only on-disk with Git, such as various rebase operations.

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#208

Earlier quoted context omitted.

This isn't true at all. We were storing binary files separately via Maven for Java projects for almost 20 years now. This was done with SVN projects. Keeping the blobs out of your source repos has been the preferred way for a long time. [Edit] The only folks who seem to want to do this are game developers, and they are generally not people you would want to emulate.

Then how come git-lfs even exists at all? There's clearly a demand for it. Whether it's good practice is up for debate. > Keeping the blobs out of your source repos has been the preferred way for a long time. This is just appeal to tradition.

> This is just appeal to tradition.

It might be, but the arguement was that we don't do it because of git.

We haven't been doing it for a long time, but that's not because of git.

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#209
post #68

Earlier quoted context omitted.

Absolutely, good for the author. However, given the numerous examples of Google pulling the plug on nonessential projects, I don’t see this as strictly positive development.

Well, it is open source, so the author or someone else could always pick it up again as a personal project if that happened.

Based on this https://devboard.gitsense.com/martinvonz/jj it looks like there are two people working on it full-time, with 7 people contributing at least 500+ lines of code churn and 14 contributing code changes. Overall the project is fairly healthy and there does appear to be enough people engaged with the project that it should continue, should Google pull the plug.

Full disclosure: This is my tool

Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful

#210
post #31

Earlier quoted context omitted.

Isn't the idea that you continue editing the working copy commit until you actually commit it? Also from the documentation: https://github.com/martinvonz/jj/blob/main/docs/git-comparis... "As a Git power-user, you may think that you need the power of the index to commit only part of the working copy. However, Jujutsu provides commands for more directly achieving most use cases you're used to using Git's index for. Fo…

Sometimes you have changes that are permanent to your repo (ie local workflow), that you always want to keep locally, but never push to the remote. In git you would always leave the changes unstage, does that mean with jj you would always have to remove them before pushing? I haven’t found an answer on the linked page. Side note: I really wish git had a way to mark commit has ‘no-push’ so they never leave your local…

In git, you have the .git/info/exclude file to track these down. Given that jj is compatible, maybe it works?

Disclaimer : I'm not on my computer, I know a file like that exists, it may not be at this exact location

Post reply on HN