git: add git colocate command

[AngelEzquerra]

This new command lets you turn a non colocated git repo into a colocated repo or vice-versa (by using the jj git colocate enable and jj git colocate disable commands respectively).
These commands simply implement the instructions found in https://github.com/jj-vcs/jj/blob/main/docs/git-compatibility.md#converting-a-repo-into-a-co-located-repo

If you just call jj git colocate (without a sub-command) a help message (with the list of sub-commands) is shown.

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, demos/)
• I have updated the config schema (cli/src/config-schema.json)
• I have added/updated tests to cover my changes

[PhilipMetzger]

This previously existed as #4833 which imo is a simpler version of this, also you squash all things from review comments into the respective parent commit, as we don't squash and merge here. The first commit message also should mention that this fixes #4624 since it is the ticket for it.

[joyously]

Is there any impact on existing workspaces or clones? (not sure if there are pointers to .git or defined remotes that would be "not found")

[AngelEzquerra]

This previously existed as #4833 which imo is a simpler version of this, also you squash all things from review comments into the respective parent commit, as we don't squash and merge here. The first commit message also should mention that this fixes #4624 since it is the ticket for it.

Sorry, when you say that you squash all things from review comments into the respective parent commit, you mean that I should squash the fixes into the original commit or that am doing that and I should not?

Also, are you saying that you'd prefer to merge #4833 rather than this version? I'm sorry I had not seen that existing PR.

[AngelEzquerra]

Is there any impact on existing workspaces or clones? (not sure if there are pointers to .git or defined remotes that would be "not found")

I don't think it affects existing workspaces, since they refer to the .jj/repo folder, I believe, which is still there.

[PhilipMetzger]

Sorry, when you say that you squash all things from review comments into the respective parent commit, you mean that I should squash the fixes into the original commit or that am doing that and I should not?

You aren't doing it, as the PR now has three commits, when it only should be one (there should be no, PR suggestions commit and the final rework also only should exist while the approach is discussed). Because the project doesn't squash merge commits and only rebases them.

Also, are you saying that you'd prefer to merge #4833 rather than this version? I'm sorry I had not seen that existing PR.

I'm pretty sure @cormacrelf won't mind if you resubmit that patch for him which would finally land this.

[AngelEzquerra]

Sorry, when you say that you squash all things from review comments into the respective parent commit, you mean that I should squash the fixes into the original commit or that am doing that and I should not?

You aren't doing it, as the PR now has three commits, when it only should be one (there should be no, PR suggestions commit and the final rework also only should exist while the approach is discussed). Because the project doesn't squash merge commits and only rebases them.

OK. I actually prefer to do what you suggest but I was worried it could cause issues with GitHub's comment tracking. I've just pushed a new version which squashes the 3 commits into one.

Also, are you saying that you'd prefer to merge #4833 rather than this version? I'm sorry I had not seen that existing PR.

I'm pretty sure @cormacrelf won't mind if you resubmit that patch for him which would finally land this.

I don't mind which one of the two PRs is merged, but if

Sorry, when you say that you squash all things from review comments into the respective parent commit, you mean that I should squash the fixes into the original commit or that am doing that and I should not?

You aren't doing it, as the PR now has three commits, when it only should be one (there should be no, PR suggestions commit and the final rework also only should exist while the approach is discussed). Because the project doesn't squash merge commits and only rebases them.

OK. Actually I prefer doing what you suggest (since it is so natural when using jj) but I was worried it might cause problems with GitHub's PR comment tracking. I just squashed all 3 changes, updated the commit message to indicate that it fixes #4624 and pushed this new version.

Also, are you saying that you'd prefer to merge #4833 rather than this version? I'm sorry I had not seen that existing PR.

I'm pretty sure @cormacrelf won't mind if you resubmit that patch for him which would finally land this.

I don't mind which PR is merged as long as one is merged, but if #4833 is preferable I think it'd be best if the original author got it through.

[glehmann]

Also, are you saying that you'd prefer to merge #4833 rather than this version? I'm sorry I had not seen that existing PR.

I'm pretty sure @cormacrelf won't mind if you resubmit that patch for him which would finally land this.

That PR was never finalized, which is unfortunate, but is something quite common when the contributor switches to something else or doesn't have time to work on it anymore.

This PR also adds a way to de-colocate the repository, that the previous one didn't have.

I there a specific reason to prefer the previous one?

[PhilipMetzger]

I there a specific reason to prefer the previous one?

It contains the start for colocated workspaces and is overall simpler by not having the --enable/--disable flags, the other PR also was stuck on a bikeshed how the reverse command should be named but that should be deferred until there's a need for it (and a native backend existing). I also suggested resubmitting his work since #4644 (comment) exists but the previous PR is still essentially a rebase away from landing.

[AngelEzquerra]

I there a specific reason to prefer the previous one?

It contains the start for colocated workspaces and is overall simpler by not having the --enable/--disable flags, the other PR also was stuck on a bikeshed how the reverse command should be named but that should be deferred until there's a need for it (and a native backend existing). I also suggested resubmitting his work since #4644 (comment) exists but the previous PR is still essentially a rebase away from landing.

I had not considered the jj workspace / git worktree integration which I guess would be nice. No reason why it could not be added later.

It's true that #4833 is a smaller change than this PR but I guess part of the reason is that it does not support undoing the co-location. Also, even though I initially proposed a similar interface for colocating a repo as what is proposed by #4833, (i.e. a simple jj git colocate command without any arguments) after the discussion in this PR I feel that using an --enable / --disable flags is the better UI. That should be easy to add to #4833 if the original author is up to it.

Honestly, I'm a little worried that unless someone makes a decision either way, both PRs will get stuck and none of them will land anytime soon.

[senekor]

In terms of the justification for this, we should consider that colocated repos will likely become the default in the October release. (#7213) So I assume the need for turning a non-colocated repo into a colocated one after the fact will be much smaller. How about the other way around? Will there be lots of people wanting to turn their default-colocated repos into non-colocated ones? I don't know.

[PhilipMetzger]

How about the other way around? Will there be lots of people wanting to turn their default-colocated repos into non-colocated ones? I don't know.

These requests are rare if you look through the Discord and GH discussions, so I'd prefer the simpler interface and defer the undoing part to a later point in the future.

[senekor]

In that case, do we need this command at all if colocated repos become the default?

[PhilipMetzger]

In that case, do we need this command at all if colocated repos become the default?

yes, since it is a useful helper in its own, since I assume there will be a bunch of people who'll want to try out the 'native' experience and switch back.

[ilyagr]

(Non-blocking) Suggestion from @algmyr on IRC:

jj git colocation enable
jj git colocation disable
jj git colocation status

[martinvonz]

@AngelEzquerra: It looks like this is pretty close to ready to merge. Do you think you will find time to finish it? No rush, though. I'm mostly just checking that you haven't forgotten about it.

[AngelEzquerra]

@AngelEzquerra: It looks like this is pretty close to ready to merge. Do you think you will find time to finish it? No rush, though. I'm mostly just checking that you haven't forgotten about it.

OK, I believe I have fixed all the nits raised by @yuja. I think it can be merged now! @yuja, can you do a final review and let me know if I can merge? Thanks!