Closed sooheon closed 7 years ago
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 :).
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
Cool, I'll try it out. To be clear, by bootstrap task should be as follows?
bootstrap:
./borg-bootstrap
make
This script only covers the "update" step, you still have to "init" first:
bootstrap:
git submodule init
./borg-bootstrap
make
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?
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.
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).
Say I have the following in my .gitmodules:
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, butgit 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?