| Commit message (Collapse) | Author | Files | Lines |
|---|
|
IIUC some part of "guix pull" makes this a symlink to a file in the
store, a read-only directory, which we can't copy into.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
system.scm
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
So we get the extra templates that exist in
`$PREFIX/share/git-core/templates` and are used when `init`ing a new
repository.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
session can be terminated
|
|
|
|
|
|
|
|
|
|
This reverts commit 11f3daea8627effd0127b28d2d46fb53af49a7fc.
Not a good idea, after all.
|
|
Now instead of working through each commit searially, we build a graph
of steps and work on that by emitting make(1) code to be executed.
May this code prove to be diffucult to modify or extend, this is a valid
commit "checkpoint" to revert to in order to recover the *exact* same
behaviour, but simpler code.
Simple benchmarks suggest that:
- on a single core, the scrit is ~15% slower;
- with 2 cores it is as fast as the original;
- as more cores are added, the faster it gets, up to $(nproc) when
using more cores doesn't change anything.
That means that it is a useful optimization for our desktops, but a
hinderance for our current server, which only has a single core.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
and report(8) scripts
|
|
|
|
|
|
|
