How to manually add a submodule remote? about emacs.g HOT 7 CLOSED

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

bootstrap:
    git submodule init
    ./borg-bootstrap
    make

from emacs.g.

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 emacscollective/borg@fac64ed.

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 magit/magit#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).

from emacs.g.

Hm, I guess by manually, it means:

cd lib/no-littering
git remote add justbur [email protected]: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 :).

from emacs.g.

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 = [email protected]:tarsius/no-littering.git
    extra-remote = justbur [email protected]:justbur/no-littering.git

from emacs.g.

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

bootstrap:
    ./borg-bootstrap
    make

from emacs.g.

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?

from emacs.g.

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.

from emacs.g.