Zimfw: [rfc] submodule update process can checkout latest commit

[kaznovac]

Description

some of the submodules are fixed on very old versions.

we can use git submodule update --remote when updating modules
it will checkout latest commit from specified branch in submodules config [master if none is specified]
more info can be found here: https://git-scm.com/book/en/v2/Git-Tools-Submodules#_pulling_in_upstream_changes

benefit is obvious, users will get latest available version of submodule

downside is that one can get into inconsistent state if there is some incompatibilities within modules or the selected branch is not stable.

i would suggest implementing two update functions [or a parameter to update command]
one that updates to zimfw repository stated submodule commits zmanage update [or zmanage update --safe]
and another to update to latest zmanage update-latest [zmanage update --latest]
and zmanage info should also list git submodule status also

p.s.
i am currently using all the latest versions without any noticeable problems - it solved me an error message from syntax-highlighter complaining about README.md not implementing some methods when using sudo -s on macos.

[ericbn]

I've made a similar change before (see #80), using git submodule foreach --quiet --recursive git pull origin master. It turned out to be a bad user experience because it left the submodule repos dirty, and then was reverted back (see #127).

You can do an "update-latest" using

cd ~/.zim && gSu

[Plloi]

@ericbn Pull #297 should address the dirty submodule problem Nevermind I'm an idiot

Flagging submodules as ignore = dirty on the other hand

[kaznovac]

@ericbn so people were confused by git status reporting submodules as 'changed', i can understand that (so was i when i used them first time)...

@Plloi ignore = dirty would ignore changes to the submodule tracked files from the main repository, but it would still report (new commits) for submodules checked out at commit other than specified in the main repository.

there is no method [that i'm aware of] that will ignore this (and there shouldn't be - it would break the purpose of this git feature)

another idea that comes to my mind is that we can 'install' external modules (this pr looks like a good start #277):

• clone the specified module in .external folder (or .remote sounds more git like)
• symlink that directory at expected location
  
  
  
  • for initial zim bootstrapping i'd suggest creating install.zsh beside init.zsh for external modules
  
  

[ericbn]

@kaznovac, I'm implementing a "plugin mechanism" in the new develop branch of Zim that solves this problem. See #323 and see https://github.com/zimfw/zimfw/tree/develop

[kaznovac]

Closing in favor of #323.

Thanks @ericbn