Hacker News Reader

Comment by cosmosgenius | Hacker News Reader

one thing which causes problem with git for me is collaborative work without using "git server". This usually comes up at homelab situation with no access a "git server" or ssh server. One thing with jj is i can use existing sharing mechanism like dropbox, google drive or if nothing else just copying jj folder (granted all of those are bad idea w.r.t vcs but still).

View on HN

I don’t understand this critique. You can copy a .git folder around just fine. You can expose a “server” by giving friends ssh keys that can only access the git stuff. In fact for a long time that’s how git “was done” at various corps.

> You can copy a .git folder around just fine.

You can do this, but due to file locking, you can corrupt the state if it's shared. jj is specifically designed so that it won't corrupt the repo in this way: https://jj-vcs.github.io/jj/latest/technical/concurrency/

Create a bare repo on the USB stick(/dropbox/Google Drive/random folder) and just push to the USB stick.

Historically speaking, this does not change things, at least for Dropbox/Google Drive. Stack Overflow is tons of posts like this: https://stackoverflow.com/questions/2199637/is-it-possible-t...

That said, I haven't tried this lately, maybe it's gotten more robust over time. But historically, even a bare repo on something like Dropbox has issues.

Sure, but this seams to be more of an issue with Dropbox, not with Git, when I run a database on Dropbox, the same problems occur. I wouldn't trust these to even preserve file attributes correctly, so I would put things into a tarball, before uploading (optionally also encrypting).

Sure, you could view it as Drobox's problem, but the core of it is that git relies on things that Dropbox doesn't support, while jj does not. And so it's usable more safely in more contexts.

I fully agree that this is a niche use-case.

JJ works when an internal file is overwritten to another version, while it does an operation? I thought that's what we are discussing here.

No, it avoids doing that (see the link someone shared above). Git actually also rarely overwrites files. The only case I'm aware of are refs, so I think it could happen that a if you modify a branch on two machines and then sync via Dropbox/rsync, one of those changes could get lost.

Ah, you mean to share the repo you are issuing git commands to directly. Yeah I would expect this to cause problems. Surprising to hear that JJ supports this.

This wasn't what I was talking about, I meant that you should create a bare repo and push to it, not that you work directly in a directory in Dropbox.

Git server is just a directory. It may or may not have actual content files in it (aka bare). In fact, any git clone of any repository is also a server on its own (and clients can have multiple "remote"s to pull from).

My go-to solution for this problem is a git init --bare --shared=group repository in a shared mountable drive. Then you can declare that repo origin, and tada, git push/pull works.

> git init --bare --shared=group

This is a very git command.

It does exactly what it says on the tin:

It calls "git" to "init"ialize a repository, which we don't need a working tree for ("bare") and that it's going to be "shared" with members of the "group".

Reply on news.ycombinator.com