Some time ago support for conf.d was added but it is currently broken if
the package does not have an `init.fish` file, given that `require`
enumerates packages through a glob on the existence of `init.fish`.
This fixes this requirement by globbing both `init.fish` and `conf.d`
entries in the `OMF_PATH`. This does generate duplicated entries, but
given that `require` already protects against double requires, this
should be safe.
Cut splits by equals sign and takes the second field. This ignores path
contents after a second equals sign. Currently this prevents the
installation on NixOS as the nix store path automatically contains a
"=".
This PR instead selects all but the first field and equals sign, leaving
the passed paths as intended.
* Change to correct argument to report accurate error message
* Update pkg/omf/functions/cli/omf.cli.theme.fish
Co-authored-by: Pablo Aguiar <scorphus@gmail.com>
Co-authored-by: Pablo Aguiar <scorphus@gmail.com>
* As omf theme <name> won't install a theme per se, changing "install" to "activate" seems clearer. So omf theme will list installed and available themes, activate a installed one, but won't install one.
* As omf theme <name> won't install a theme per se, changing "install" to
"activate" seems clearer. So omf theme will list installed and available
themes, activate a installed one, but won't install one.
I didn't have much time to invest in `tools/generate-themes.doc.fish`,
unfortuntely. It's far from perfect, but fairly usable. Please, refer
to instructions in the header.
Fix#795, #800, #771
* Install package according to branch information in repo
* Add branch information for update package
* add double quotes for $branch
Signed-off-by: Yang Keao <keao.yang@yahoo.com>
For example, "git diff" would print
"fatal: this operation must be run in a work tree"
We could still run git_branch_name in bare repositories in future.
Some git commands require to be run from inside the worktree (as opposed
to the git dir, although it's usually in .git). This commit adds
a function git_is_worktree to check this. It is used for the commands
that need the worktree instead of git_is_repo.
An alternative solution might have been to find the git worktree in the
parent of the git directory, but this doesn't work for all cases.
Generally it's impossible to detect the location of the worktree (plus
it's not unique).
Co-authored-by: Pablo Aguiar <scorphus@gmail.com>