How to manually add a submodule remote?

[sooheon]

Say I have the following in my .gitmodules:

[submodule "no-littering"]
    path = lib/no-littering
    url = git@github.com:tarsius/no-littering.git

Now through the magit interface, I added a remote git@github.com:justbur/no-littering.git to use its fork. This works just fine on the same machine, but git submodule update --init fails on a new machine, complaining it can't find the commit. The announcement mentions you have to keep track of this manually, how is that done?

[sooheon]

Hm, I guess by manually, it means:

cd lib/no-littering
git remote add justbur git@github.com:justbur/no-littering.git
git fetch --all
git checkout $RELEVANT_COMMIT

Then git submodule update will continue. So you're right, this is really tedious, and there should be a better way :).

[tarsius]

This is the main reason I released Borg as v0.1.0 instead of v1.0.0. It's a major issue, which I think would be best fixed by teaching git submodule itself about "additional remotes".

Meanwhile you can use this script. You should add that to the .emacs.d repository and adjust Makefile to call it, instead of git submodule update.

You then have to set the additional remotes in .gitmodules, e.g.:

[submodule "no-littering"]
    path = lib/no-littering
    url = git@github.com:tarsius/no-littering.git
    extra-remote = justbur git@github.com:justbur/no-littering.git

[sooheon]

Cool, I'll try it out. To be clear, by bootstrap task should be as follows?

bootstrap:
    ./borg-bootstrap
    make

[tarsius]

This script only covers the "update" step, you still have to "init" first:

bootstrap:
    git submodule init
    ./borg-bootstrap
    make

[tarsius]

The emacs.g collective now ships with the borg-bootstrap script and uses it for the bootstrap make target. submodule.NAME.extra-remote has been renamed to just submodule.NAME.remote. The documentation has been updated accordingly, but I haven't released a new borg version since I have don this.

By the way, are you still using borg? Care to share your experience?

[sooheon]

I like borg, but the thing that kept me from completely moving over to it is that for the same set of packages, borg-initialize simply took longer than package-initialize.

The smoother workflow to fork and contribute to packages was really nice. I like being able to maintain a branch of a package long-term, with my additions. I also like that conceptually it's a bit more "bare metal" than package.el. You're managing your packages with git, not elisp. But these benefits are not worth a >2 second increase in init time for me, and I would love it if the conceptually leaner and meaner borg also felt more lightweight at startup. I'm curious where this would rank on your priorities for borg?

Oh also, I couldn't figure out a convenient way to update packages across the board at once.

[tarsius]

Thanks for the feedback!

But these benefits are not worth a >2 second increase in init time for me

Are you using Windows? If so, you might want to try again. On that OS a big slowdown was due to git config being called many times during startup and that has been fixed with https://github.com/emacscollective/borg/commit/fac64edc933a1151474849f92c29a0489a05bdec.

I'm curious where [performance] would rank on your priorities for borg?

Not very high, that being said, I wasn't aware of the above issue until shortly before I addressed it, so if there are other performance issues and someone tells me about them, then I might to something about them anyway.

Oh also, I couldn't figure out a convenient way to update packages across the board at once.

There currently isn't a command to do that, and I probably won't add one to borg itself, but there is a change cooking in magit (which somehow ended up on the slow-lane, in a quite unusual fashion). The original pr is https://github.com/magit/magit/pull/2674, but it is more likely that something like https://github.com/magit/magit/tree/np/submodules-v2 will be merged (I am going to rebase that shortly).