Where can I find the git root? (Is there one?)

[jeanbza]

The nebula gradle plugin requires the project you're working in to have a git root. It goes and does git-y things to figure out what release to push next based off the git tags.

Thankfully it allows you to specify a -Pgit.root=some/dir, but I'm not sure whether jj maintains a git dir (the .git/ dir in most git clone-d projects), and if so where to find it.

I did try find . | grep git and came up with .jj/repo/store/git, but that didn't work:

$ gw installDist -Pgit.root=.jj/repo/store/git

> Configure project :
Git repository not found at .jj/repo/store/git -- nebula-release tasks will not be available. Use the git.root Gradle property to specify a different directory.

I also tried ln -s .jj/repo/store/git .jj/repo/store/.git && gw installDist -Pgit.root=.jj/repo/store/ just in case it was looking for a .git/ specifically, and no dice. :)

Looking at a real .git/ and jj's .jj/repo/store/git/ I do see differences:

$ ls .jj/repo/store/git
FETCH_HEAD  HEAD        config      description hooks       info        objects     refs

$ ls .git
COMMIT_EDITMSG ORIG_HEAD      hooks          logs           refs
FETCH_HEAD     config         index          objects
HEAD           description    info           packed-refs

So, I guess that folder is probably not what I'm looking for.

tldr

Is there a real .git/ folder somewhere in .jj/? If so, where?

[jeanbza]

Alternatively can I git co-locate, run gradle, and undo the git co-locate? Is that easy / non-destructive or would that be a nuisance somehow?

[bnjmnt4n]

Taking a quick search through the source code, it seems like the plugin expects the "root directory" to be a worktree containing the .git folder: https://github.com/nebula-plugins/nebula-release-plugin/blob/7bc718e1064acbfb856271ad70ea762afd45aec6/src/main/groovy/nebula/plugin/release/git/command/GitReadCommand.groovy#L28

Most like co-locating would be the way to go.

[steveklabnik]

Just found this too! Yep.

[steveklabnik]

I find this interesting! it used to work as a "real" git directory, and that is even advertised in the docs: https://jj-vcs.github.io/jj/latest/github/#using-github-cli

but now

❯ git --git-dir=.jj/repo/store/git log
fatal: not a git repository: '.jj/repo/store/git'

Very interesting!

EDIT: when I tested this, i wasn't using the git backend, so .jj/repo/store/git didn't even exist. oops! in a real repository, it does.

[jeanbza]

Here's what I get:

$ git --git-dir=.jj/repo/store/git log
fatal: your current branch 'main' does not have any commits yet

[jennings]

It should be a real Git repository.

The file .jj/repo/store/git_target contains the path to the git repository that jj is using. If that file contains "../../../.git", then you have a colocated repository. If it contains any other value, your repository is not colocated (and the value tells you where the git directory is).

The other likely value is "git", which means .jj/repo/store/git is the backing Git repository.

[jeanbza]

$ cat .jj/repo/store/git_target
git

To answer your first question.

And, you're right, it seems to be a git repo with almost no information:

$ git log
fatal: your current branch 'main' does not have any commits yet
$ git branch -v
$ git status
fatal: this operation must be run in a work tree
$ git remote -v
origin	https://blah.git (fetch)
origin	https://blah.git (push)

[jeanbza]

Perhaps the best thing that I can do is clone this off to the side and point the nebula plugin at it? 🤔

[emilazy]

Do you just need jj git clone --colocate?

[jeanbza]

Well, I'd prefer not to live in a colocated repo. I've done that before and had issues: native jj repos are easier. So if I colocate, I'd like to know whether it's easy to quickly and non-destructively undo the colocate.

[shanesveller]

I'd prefer not to live in a colocated repo
I've done that before and had issues

Please consider filing bug reports where possible so they can be triaged, because that quality of experience matters a lot for adoption.

I don't have any stats, but I would wager informally that probably most jujutsu users are routinely using colocated mode day in and day out, so I don't think it's likely to be fundamentally broken or buggy for broad use, at least for Mac and Linux users. And for those that do, their motives are often toward preserving compatibility with tools and workflows that explicitly assume Git, as you have here.

[hotsphink]

For the record, my programmatic way of finding the git dir from a jj workspace. This may be incomplete or just plain wrong:

1. $wsroot = jj workspace root
2. $jjrepo = $wsroot/.jj/repo
3. if $jjrepo is a file, $jjrepo = the file contents of $jjrepo
4. $git_target = the file contents of $jjrepo/store/git_target
5. $git_repo = $jjrepo/store/$git_target

I have only tested the 2 scenarios I have lying around (a colocated jj repo, and a workspace of that repo).

This makes me think it would be nice to have jj git root.

[jennings]

You can simplify this a bit: Update: I'm wrong!

jjrepo=$(jj root)/.jj/repo

[hotsphink]

As far as I can tell, jj root and jj workspace root are identical, so I'm unclear on what step that removes. Unless you just mean s/jj workspace root/jj root/

Why isn't there a command to find the, uh, root of the "root" (default?) workspace?

[jennings]

You're right, sorry! I could have sworn jj root always gave the workspace root for where the .jj repository lives, but it doesn't.

[martinvonz]

I think there were some plans to make jj root able to also tell you about the main workspace path (and/or the .jj/repo/ inside it?). I think jj git root makes sense, in case someone feels like implementing that. Should be very simple.

[cole-h]

I was just about to attempt to implement jj git root, but there's already a PR up 🎉 #6128

EDIT: and now it's been merged!