search

martinvonz / jj

A Git-compatible VCS that is both simple and powerful
https://martinvonz.github.io/jj/
Apache License 2.0
8.93k stars 310 forks source link

FR: Native submodules, submodule specific config #2919

Open AidanWelch opened 9 months ago

AidanWelch commented 9 months ago

Imagine being able to use submodules to explicitly link to a library repository, you could have submodule specific ignore files, so you could for example only include the one header library, and not the test suite. In my opinion, proper submodule support rather than after thoughts is one of the biggest things missing from any VCS I've seen. You could match based on tags, or always pull the latest revision, or of course a specific revision. I am not asking for package management, for example submodules shouldn't avoid repeating repositories. Admittedly not a very coherent feature request, I'm not very familiar with jj, but just wanted to request something often overlooked in VCS

arxanas commented 9 months ago

Will possibly relate to the design in https://github.com/martinvonz/jj/pull/2877

ilyagr commented 9 months ago

As far as I understand, this is not the kind of submodules you want, but I feel this should still link to #494 about supporting Git submodules.

jyn514 commented 8 months ago

i haven't looked into https://github.com/martinvonz/jj/pull/2877, but i had a great conversation with @sunshowers a while ago about why git submodules are so hard to use:

Let's define what submodules are:

  1. references to other repositories ("subrepositories") checked into a repository ("the main repository"), that are hash-addressed
  2. managed by the source control system itself
  3. present a read-write interface which means that you can edit the contents of the subrepository and have them reflected in the main repository

So submodules have a few UI issues specific to git:

  1. they're a super leaky abstraction -- why do you have to run git submodule init/update? (I know there's a command for it but it doesn't make sense to have that be leaky at all) -- why does git status have an --ignore-submodules argument with a number of different settings?
  2. changing a submodule to a directory, or renaming a submodule, has a terrible UX, with no real path to fixing it

But the inherent issue is that the read-write paradigm is broken and cannot be fixed. when you're in a repository, you expect all files managed by the repository to behave the same way. you expect git add to add the file, git rm to remove the file, git commit from anywhere in the repo to make a commit. this is true everywhere except submodules (and large files/lfs, though the ground there is a bit less shaky).

Either files are meant to be edited or they're not. something like submodules that presents a read-only interface would be fine. package managers with repository/path dependencies are fine because the boundaries are clear in that case. submodules are just a giant conceptual mess

i agree with basically all of this, but i think that git subtree has the right model for fixing these problems: git add works exactly as it does in the parent repository, without having to remember whether you're running git for the submodule or for the parent. josh is basically just subtree but faster/less buggy/better UI, and i know people using that who are happy with it, unlike subtree or submodule.

frankly, i think the read-only case does not need to be supported natively in a VCS, if you need that for some reason you can run jj git clone in your build system (or better yet just download a zip, since you're not editing it and don't need to waste bandwidth downloading the history). only the read-write case needs native support, and for that there's better options than the git submodule paradigm.

sunshowers commented 8 months ago

(I still believe in all of that. I've used subtrees a couple of times and they've been okay—my preference remains for the build system to do the resolution though)