Add a plugin mechanism \o/
This is a major change, where Zsh modules/plugins are not git submodules
in the Zim repo anymore, but customized and installed separately as
individual repositories. The discussion about this started more than 2
years ago in #88. Closes #299.
This will allow contributors' modules to live in their own repositories.
See #33, #138, #262, #281, #324.
The current code has what, up to this point, I considered to be the best
balance between simplicity, execution speed and number of files.
One measured decision was to make the initialization of modules depend
only on the `':zim' modules` style, keeping it as fast as possible.
The `':zim:module' module` style is used to install, update and clean
the modules, all operations that happen after the user got his
as-blazing-fast-possible shell prompt.
Even though I didn't care much about making install or update fast,
`xargs` has a nice feature of allowing commands to be executed in
parallel with `-P`. I took advantage of that.
I've also worked on making the `zimfw` utility give the user some nice
(while still minimalistic) output. Also I'm suggesting this as the new
name for the `zmanage` tool, since `zimfw` does not shadow the `zim`
wiki tool.
2019-01-07 18:25:34 -05:00
|
|
|
# This runs in a new shell
|
2019-12-01 16:00:47 -05:00
|
|
|
readonly MODULE=${1}
|
|
|
|
readonly DIR=${2}
|
|
|
|
readonly URL=${3}
|
|
|
|
readonly TYPE=${4}
|
|
|
|
readonly REV=${5}
|
|
|
|
readonly -i QUIET=${6}
|
|
|
|
readonly CLEAR_LINE=$'\E[2K\r'
|
|
|
|
(( ! QUIET )) && print -Rn ${CLEAR_LINE}"Updating ${MODULE} …"
|
2019-12-12 08:46:27 -05:00
|
|
|
if ! builtin cd -q ${DIR} 2>/dev/null; then
|
2019-12-01 16:00:47 -05:00
|
|
|
print -u2 -PR ${CLEAR_LINE}"%F{red}✗ %B${MODULE}:%b Not installed%f"
|
Add a plugin mechanism \o/
This is a major change, where Zsh modules/plugins are not git submodules
in the Zim repo anymore, but customized and installed separately as
individual repositories. The discussion about this started more than 2
years ago in #88. Closes #299.
This will allow contributors' modules to live in their own repositories.
See #33, #138, #262, #281, #324.
The current code has what, up to this point, I considered to be the best
balance between simplicity, execution speed and number of files.
One measured decision was to make the initialization of modules depend
only on the `':zim' modules` style, keeping it as fast as possible.
The `':zim:module' module` style is used to install, update and clean
the modules, all operations that happen after the user got his
as-blazing-fast-possible shell prompt.
Even though I didn't care much about making install or update fast,
`xargs` has a nice feature of allowing commands to be executed in
parallel with `-P`. I took advantage of that.
I've also worked on making the `zimfw` utility give the user some nice
(while still minimalistic) output. Also I'm suggesting this as the new
name for the `zmanage` tool, since `zimfw` does not shadow the `zim`
wiki tool.
2019-01-07 18:25:34 -05:00
|
|
|
return 1
|
|
|
|
fi
|
2019-01-12 15:56:00 -05:00
|
|
|
if [[ ${PWD} != $(command git rev-parse --show-toplevel 2>/dev/null) ]]; then
|
|
|
|
# Not in repo root. Will not try to update.
|
Add a plugin mechanism \o/
This is a major change, where Zsh modules/plugins are not git submodules
in the Zim repo anymore, but customized and installed separately as
individual repositories. The discussion about this started more than 2
years ago in #88. Closes #299.
This will allow contributors' modules to live in their own repositories.
See #33, #138, #262, #281, #324.
The current code has what, up to this point, I considered to be the best
balance between simplicity, execution speed and number of files.
One measured decision was to make the initialization of modules depend
only on the `':zim' modules` style, keeping it as fast as possible.
The `':zim:module' module` style is used to install, update and clean
the modules, all operations that happen after the user got his
as-blazing-fast-possible shell prompt.
Even though I didn't care much about making install or update fast,
`xargs` has a nice feature of allowing commands to be executed in
parallel with `-P`. I took advantage of that.
I've also worked on making the `zimfw` utility give the user some nice
(while still minimalistic) output. Also I'm suggesting this as the new
name for the `zmanage` tool, since `zimfw` does not shadow the `zim`
wiki tool.
2019-01-07 18:25:34 -05:00
|
|
|
return 0
|
|
|
|
fi
|
|
|
|
if [[ ${URL} != $(command git config --get remote.origin.url) ]]; then
|
2019-12-01 16:00:47 -05:00
|
|
|
print -u2 -PR ${CLEAR_LINE}"%F{red}✗ %B${MODULE}:%b URL does not match. Expected ${URL}. Will not try to update.%f"
|
Add a plugin mechanism \o/
This is a major change, where Zsh modules/plugins are not git submodules
in the Zim repo anymore, but customized and installed separately as
individual repositories. The discussion about this started more than 2
years ago in #88. Closes #299.
This will allow contributors' modules to live in their own repositories.
See #33, #138, #262, #281, #324.
The current code has what, up to this point, I considered to be the best
balance between simplicity, execution speed and number of files.
One measured decision was to make the initialization of modules depend
only on the `':zim' modules` style, keeping it as fast as possible.
The `':zim:module' module` style is used to install, update and clean
the modules, all operations that happen after the user got his
as-blazing-fast-possible shell prompt.
Even though I didn't care much about making install or update fast,
`xargs` has a nice feature of allowing commands to be executed in
parallel with `-P`. I took advantage of that.
I've also worked on making the `zimfw` utility give the user some nice
(while still minimalistic) output. Also I'm suggesting this as the new
name for the `zmanage` tool, since `zimfw` does not shadow the `zim`
wiki tool.
2019-01-07 18:25:34 -05:00
|
|
|
return 1
|
|
|
|
fi
|
2019-01-22 19:40:43 -05:00
|
|
|
if [[ ${TYPE} == tag ]]; then
|
Add a plugin mechanism \o/
This is a major change, where Zsh modules/plugins are not git submodules
in the Zim repo anymore, but customized and installed separately as
individual repositories. The discussion about this started more than 2
years ago in #88. Closes #299.
This will allow contributors' modules to live in their own repositories.
See #33, #138, #262, #281, #324.
The current code has what, up to this point, I considered to be the best
balance between simplicity, execution speed and number of files.
One measured decision was to make the initialization of modules depend
only on the `':zim' modules` style, keeping it as fast as possible.
The `':zim:module' module` style is used to install, update and clean
the modules, all operations that happen after the user got his
as-blazing-fast-possible shell prompt.
Even though I didn't care much about making install or update fast,
`xargs` has a nice feature of allowing commands to be executed in
parallel with `-P`. I took advantage of that.
I've also worked on making the `zimfw` utility give the user some nice
(while still minimalistic) output. Also I'm suggesting this as the new
name for the `zmanage` tool, since `zimfw` does not shadow the `zim`
wiki tool.
2019-01-07 18:25:34 -05:00
|
|
|
if [[ ${REV} == $(command git describe --tags --exact-match 2>/dev/null) ]]; then
|
2019-12-01 16:00:47 -05:00
|
|
|
(( ! QUIET )) && print -PR ${CLEAR_LINE}"%F{green}✓%f %B${MODULE}:%b Already up to date"
|
Add a plugin mechanism \o/
This is a major change, where Zsh modules/plugins are not git submodules
in the Zim repo anymore, but customized and installed separately as
individual repositories. The discussion about this started more than 2
years ago in #88. Closes #299.
This will allow contributors' modules to live in their own repositories.
See #33, #138, #262, #281, #324.
The current code has what, up to this point, I considered to be the best
balance between simplicity, execution speed and number of files.
One measured decision was to make the initialization of modules depend
only on the `':zim' modules` style, keeping it as fast as possible.
The `':zim:module' module` style is used to install, update and clean
the modules, all operations that happen after the user got his
as-blazing-fast-possible shell prompt.
Even though I didn't care much about making install or update fast,
`xargs` has a nice feature of allowing commands to be executed in
parallel with `-P`. I took advantage of that.
I've also worked on making the `zimfw` utility give the user some nice
(while still minimalistic) output. Also I'm suggesting this as the new
name for the `zmanage` tool, since `zimfw` does not shadow the `zim`
wiki tool.
2019-01-07 18:25:34 -05:00
|
|
|
return 0
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
if ! ERR=$(command git fetch -pq origin ${REV} 2>&1); then
|
2019-12-01 16:00:47 -05:00
|
|
|
print -u2 -PR ${CLEAR_LINE}"%F{red}✗ %B${MODULE}:%b Error during git fetch%f"$'\n'${(F):- ${(f)^ERR}}
|
Add a plugin mechanism \o/
This is a major change, where Zsh modules/plugins are not git submodules
in the Zim repo anymore, but customized and installed separately as
individual repositories. The discussion about this started more than 2
years ago in #88. Closes #299.
This will allow contributors' modules to live in their own repositories.
See #33, #138, #262, #281, #324.
The current code has what, up to this point, I considered to be the best
balance between simplicity, execution speed and number of files.
One measured decision was to make the initialization of modules depend
only on the `':zim' modules` style, keeping it as fast as possible.
The `':zim:module' module` style is used to install, update and clean
the modules, all operations that happen after the user got his
as-blazing-fast-possible shell prompt.
Even though I didn't care much about making install or update fast,
`xargs` has a nice feature of allowing commands to be executed in
parallel with `-P`. I took advantage of that.
I've also worked on making the `zimfw` utility give the user some nice
(while still minimalistic) output. Also I'm suggesting this as the new
name for the `zmanage` tool, since `zimfw` does not shadow the `zim`
wiki tool.
2019-01-07 18:25:34 -05:00
|
|
|
return 1
|
|
|
|
fi
|
2019-01-22 19:40:43 -05:00
|
|
|
if [[ ${TYPE} == branch ]]; then
|
2019-12-01 16:00:47 -05:00
|
|
|
LOG_REV=${REV}@{u}
|
Add a plugin mechanism \o/
This is a major change, where Zsh modules/plugins are not git submodules
in the Zim repo anymore, but customized and installed separately as
individual repositories. The discussion about this started more than 2
years ago in #88. Closes #299.
This will allow contributors' modules to live in their own repositories.
See #33, #138, #262, #281, #324.
The current code has what, up to this point, I considered to be the best
balance between simplicity, execution speed and number of files.
One measured decision was to make the initialization of modules depend
only on the `':zim' modules` style, keeping it as fast as possible.
The `':zim:module' module` style is used to install, update and clean
the modules, all operations that happen after the user got his
as-blazing-fast-possible shell prompt.
Even though I didn't care much about making install or update fast,
`xargs` has a nice feature of allowing commands to be executed in
parallel with `-P`. I took advantage of that.
I've also worked on making the `zimfw` utility give the user some nice
(while still minimalistic) output. Also I'm suggesting this as the new
name for the `zmanage` tool, since `zimfw` does not shadow the `zim`
wiki tool.
2019-01-07 18:25:34 -05:00
|
|
|
else
|
|
|
|
LOG_REV=${REV}
|
|
|
|
fi
|
|
|
|
LOG=$(command git log --graph --color --format='%C(yellow)%h%C(reset) %s %C(cyan)(%cr)%C(reset)' ..${LOG_REV} 2>/dev/null)
|
|
|
|
if ! ERR=$(command git checkout -q ${REV} -- 2>&1); then
|
2019-12-01 16:00:47 -05:00
|
|
|
print -u2 -PR ${CLEAR_LINE}"%F{red}✗ %B${MODULE}:%b Error during git checkout%f"$'\n'${(F):- ${(f)^ERR}}
|
Add a plugin mechanism \o/
This is a major change, where Zsh modules/plugins are not git submodules
in the Zim repo anymore, but customized and installed separately as
individual repositories. The discussion about this started more than 2
years ago in #88. Closes #299.
This will allow contributors' modules to live in their own repositories.
See #33, #138, #262, #281, #324.
The current code has what, up to this point, I considered to be the best
balance between simplicity, execution speed and number of files.
One measured decision was to make the initialization of modules depend
only on the `':zim' modules` style, keeping it as fast as possible.
The `':zim:module' module` style is used to install, update and clean
the modules, all operations that happen after the user got his
as-blazing-fast-possible shell prompt.
Even though I didn't care much about making install or update fast,
`xargs` has a nice feature of allowing commands to be executed in
parallel with `-P`. I took advantage of that.
I've also worked on making the `zimfw` utility give the user some nice
(while still minimalistic) output. Also I'm suggesting this as the new
name for the `zmanage` tool, since `zimfw` does not shadow the `zim`
wiki tool.
2019-01-07 18:25:34 -05:00
|
|
|
return 1
|
|
|
|
fi
|
2019-01-22 19:40:43 -05:00
|
|
|
if [[ ${TYPE} == branch ]]; then
|
Add a plugin mechanism \o/
This is a major change, where Zsh modules/plugins are not git submodules
in the Zim repo anymore, but customized and installed separately as
individual repositories. The discussion about this started more than 2
years ago in #88. Closes #299.
This will allow contributors' modules to live in their own repositories.
See #33, #138, #262, #281, #324.
The current code has what, up to this point, I considered to be the best
balance between simplicity, execution speed and number of files.
One measured decision was to make the initialization of modules depend
only on the `':zim' modules` style, keeping it as fast as possible.
The `':zim:module' module` style is used to install, update and clean
the modules, all operations that happen after the user got his
as-blazing-fast-possible shell prompt.
Even though I didn't care much about making install or update fast,
`xargs` has a nice feature of allowing commands to be executed in
parallel with `-P`. I took advantage of that.
I've also worked on making the `zimfw` utility give the user some nice
(while still minimalistic) output. Also I'm suggesting this as the new
name for the `zmanage` tool, since `zimfw` does not shadow the `zim`
wiki tool.
2019-01-07 18:25:34 -05:00
|
|
|
if ! OUT=$(command git merge --ff-only --no-progress -n 2>&1); then
|
2019-12-01 16:00:47 -05:00
|
|
|
print -u2 -PR ${CLEAR_LINE}"%F{red}✗ %B${MODULE}:%b Error during git merge%f"$'\n'${(F):- ${(f)^OUT}}
|
Add a plugin mechanism \o/
This is a major change, where Zsh modules/plugins are not git submodules
in the Zim repo anymore, but customized and installed separately as
individual repositories. The discussion about this started more than 2
years ago in #88. Closes #299.
This will allow contributors' modules to live in their own repositories.
See #33, #138, #262, #281, #324.
The current code has what, up to this point, I considered to be the best
balance between simplicity, execution speed and number of files.
One measured decision was to make the initialization of modules depend
only on the `':zim' modules` style, keeping it as fast as possible.
The `':zim:module' module` style is used to install, update and clean
the modules, all operations that happen after the user got his
as-blazing-fast-possible shell prompt.
Even though I didn't care much about making install or update fast,
`xargs` has a nice feature of allowing commands to be executed in
parallel with `-P`. I took advantage of that.
I've also worked on making the `zimfw` utility give the user some nice
(while still minimalistic) output. Also I'm suggesting this as the new
name for the `zmanage` tool, since `zimfw` does not shadow the `zim`
wiki tool.
2019-01-07 18:25:34 -05:00
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
# keep just first line of OUT
|
|
|
|
OUT=${OUT%%($'\n'|$'\r')*}
|
|
|
|
else
|
|
|
|
OUT="Updating to ${TYPE} ${REV}"
|
|
|
|
fi
|
|
|
|
if ERR=$(command git submodule update --init --recursive -q 2>&1); then
|
2019-12-01 16:00:47 -05:00
|
|
|
if (( ! QUIET )); then
|
|
|
|
[[ -n ${LOG} ]] && OUT=${OUT}$'\n'${(F):- ${(f)^LOG}}
|
|
|
|
print -PR ${CLEAR_LINE}"%F{green}✓%f %B${MODULE}:%b ${OUT}"
|
Add a plugin mechanism \o/
This is a major change, where Zsh modules/plugins are not git submodules
in the Zim repo anymore, but customized and installed separately as
individual repositories. The discussion about this started more than 2
years ago in #88. Closes #299.
This will allow contributors' modules to live in their own repositories.
See #33, #138, #262, #281, #324.
The current code has what, up to this point, I considered to be the best
balance between simplicity, execution speed and number of files.
One measured decision was to make the initialization of modules depend
only on the `':zim' modules` style, keeping it as fast as possible.
The `':zim:module' module` style is used to install, update and clean
the modules, all operations that happen after the user got his
as-blazing-fast-possible shell prompt.
Even though I didn't care much about making install or update fast,
`xargs` has a nice feature of allowing commands to be executed in
parallel with `-P`. I took advantage of that.
I've also worked on making the `zimfw` utility give the user some nice
(while still minimalistic) output. Also I'm suggesting this as the new
name for the `zmanage` tool, since `zimfw` does not shadow the `zim`
wiki tool.
2019-01-07 18:25:34 -05:00
|
|
|
fi
|
|
|
|
else
|
2019-12-01 16:00:47 -05:00
|
|
|
print -u2 -PR ${CLEAR_LINE}"%F{red}✗ %B${MODULE}:%b Error during git submodule update%f"$'\n'${(F):- ${(f)^ERR}}
|
Add a plugin mechanism \o/
This is a major change, where Zsh modules/plugins are not git submodules
in the Zim repo anymore, but customized and installed separately as
individual repositories. The discussion about this started more than 2
years ago in #88. Closes #299.
This will allow contributors' modules to live in their own repositories.
See #33, #138, #262, #281, #324.
The current code has what, up to this point, I considered to be the best
balance between simplicity, execution speed and number of files.
One measured decision was to make the initialization of modules depend
only on the `':zim' modules` style, keeping it as fast as possible.
The `':zim:module' module` style is used to install, update and clean
the modules, all operations that happen after the user got his
as-blazing-fast-possible shell prompt.
Even though I didn't care much about making install or update fast,
`xargs` has a nice feature of allowing commands to be executed in
parallel with `-P`. I took advantage of that.
I've also worked on making the `zimfw` utility give the user some nice
(while still minimalistic) output. Also I'm suggesting this as the new
name for the `zmanage` tool, since `zimfw` does not shadow the `zim`
wiki tool.
2019-01-07 18:25:34 -05:00
|
|
|
return 1
|
|
|
|
fi
|