undefined

points

by dgb2312 hours ago |

comments

by verdverm10 hours ago|

[-]

Unless you use LFS, submodules, or hooks at your org.

by igor477 hours ago|

parent|

[-]

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

by verdverm6 hours ago|

parent|

[-]

The git compatibility page states that submodules are not supported

https://docs.jj-vcs.dev/latest/git-compatibility/

by steveklabnik6 hours ago|

parent|

[-]

What "not supported" means with submodules specifically is that jj doesn't have commands to manage them. You can use git commands to manage them, and it does, in my understanding, work. There's just no native support yet.

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.

by rstuart413315 minutes ago|

parent|

[-]

> and it does, in my understanding, work.

I use submodules with jj, and jj saves and restores submodule hashes perfectly. What it doesn't do is manipulate the sub-repository from its parent. You can do that yourself using jj or git of course, which is what I ended up doing using a few scripts. The result ended up being more reliable than using git's submodule commands directly.

They can take all the time in the world to implement submodules as far as I'm concerned. jj's implementation of workspaces removes all of the hairs of git's worktrees. git submodule implementation has even more hairs than worktrees. If the jj developers need time to do as good a job on submodules as they did with workspaces, then I say give it to them.

by jeremyjh11 hours ago|

prev|

[-]

But this is not true. They are interoperable but far from seamless. Those features mainly support migration use cases or things like git deployment from an repo managed in jj. Operations git does are not in jj’s log. You have to constantly import them. The project recommends a single primary interface.

by miyoji11 hours ago|

parent|

[-]

But it is true. I (and many others) happily use jj on teams that use git without anyone else on the team using jj or knowing (or caring) what I'm using.

by ongy10 hours ago|

parent|

prev|

[-]

I think you are talking about colocation, which is slightly different than the `jj git push` `jj git fetch` type commands.

Colocation has its uses bit is a bit finicky. The push/pull compatibility works perfectly fine (with some caveats of github being broken that can be worked around).

by maleldil11 hours ago|

parent|

prev|

[-]

If you constantly switch between the two, you're going to have a hard time, but you can take a git repo, try jj for a while, and if you decide to go back, you don't lose anything.

by jeremyjh10 hours ago|

parent|

[-]

Right, but that’s different from working in a team environment where everyone else continues using git.

by stouset9 hours ago|

parent|

[-]

No?

What problems, exactly, are you suggesting exist? I have used jj extensively on git teams and it has been seamless. The only people who have noticed or cared are the coworkers I’ve gotten to join me.

by saghm10 hours ago|

parent|

prev|

[-]

How so? I've used `jj` locally on teams where most (if not all) of the other team members were using git, and they only found out I was using `jj` when I told them.

by maleldil4 hours ago|

parent|

prev|

[-]

You're confusing mixing git and jj in your local copy of the repo vs what it looks like to other people. You can use jj locally, and it interoperates perfectly with any git remote, and no one has to know you're even using it. From the point of view of other people, it doesn't matter.

by pyreko9 hours ago|

parent|

prev|

[-]

fwiw I don't use it personally but some people on my team use it while the others use git, and nobody complains.

by tonfa6 hours ago|

parent|

[-]

Yeah same here, have been using jj exclusively, the only reason people notice is because my branch names default to the changeid in my setup so I've had questions about the random looking strings.

by asdfasgasdgasdg10 hours ago|

parent|

prev|

[-]

Most importantly, submodules are not fully supported, which are used by almost every open source project at least in the space I work in (embedded). So you can't use jj to easily contribute back to those project. It can be done but you always have to be cognizant of whether a submodule has changed between two branches or when you sync, since they don't update automatically the way they do with git.

by saghm10 hours ago|

parent|

prev|

[-]

It's been over a year since I last used git manually in the CLI, and I've exclusively worked with git remotes. The only time I had any friction was on a team where stale code-gen output was checked into the repo and for whatever reason no one was willing to either add it to the `.gitignore` or commit (pun intended) to keeping it up to date, meaning that I had to manually remove the changes from when I compiled before pushing. I would have argued in favor of adding to .gitignore or keeping it up to date even if I didn't use `jj` though because I think having stale output checked in is just silly.

by nchagnet4 hours ago|

parent|

[-]

For what it's worth, you can have your own local gitignore by adding patterns to .git/info/exclude. It's quite useful in this exact situation.

by saghm2 hours ago|

parent|

[-]

I did try this, but for whatever reason it kept getting added back automatically. I forget the details of exactly why it was happening because it was close to a year ago, and in the compatibility guide it says this is supported, but I'm not sure if it was at the time or I was running into something different. This was a contract gig for me where I knew it would be ending within a month or so, which meant I didn't bother spending a ton of time trying to figure out a long-term solution.

by eru11 hours ago|

prev|

[-]

Funnily enough, that's how I used git with CVS and Subversion, too.

by IshKebab10 hours ago|

prev|

[-]

Big caveat: do not try to use Git and JJ in the same directory. It's probably fine if you only use JJ, but if you mix them you will horribly break things.

by chriswarbo8 hours ago|

parent|

[-]

I suppose it depends what you mean by "horribly break things".

The only thing I've noticed is that `jj` will leave the git repo with either a detached HEAD, or with a funny `@` ref checked out.

I don't think that would trouble someone who's experienced with git and knows its "DAG of commits" model.

For someone who's less experienced, or only uses git for a set of branches with mostly linear history (like a sort of "fancy undo"), I could imagine getting a shock when trying to `git commit` and not seeing them on any of the branches!

by nailer3 hours ago|

parent|

[-]

> I don't think that would trouble someone who's experienced with git and knows its "DAG of commits" model.

I think most people that have git experience don't know what a DAG is and have never used reflog.

by surajrmal9 hours ago|

parent|

prev|

[-]

This isn't true?

by IshKebab9 hours ago|

parent|

[-]

It is when I tried it.

by stouset9 hours ago|

parent|

[-]

Jujutsu uses git as its primary backing store and synthesizes anything else it needs on top on-the-fly. Any incompatibility here is considered a serious bug.

Obviously I can’t argue against your lived experience, but it is neither typical nor common. This is quite literally an explicitly-supported use, and one that many people do daily.