2 registration mechanism: 1 for installed wrappers, 1 for once run through base-template.sh

[gabyx]

Just a thought @rycus86 , @matthijskooijman : For another PR: Could we also register repos in the core.useCoreHooksPath mode. So the registered file has now the notion of all repos which have once run through the base-template.sh. Maybe it would be good if we would have two registration files:

• File installed: The same as the registered file now, jsut renamed
• File triggered: All repos which have once run base-template.sh

This way enables us to have more control later on install migration stuff in the future.

[rycus86]

How's triggered different from registered? We just need a list of all the repos that run our hooks, don't we?

[gabyx]

Yes but we dont know which ones habe installes wrappers or is probably not so important we anyway search for a string inside the wrapper to be sure its rhe wrapper

Von meinem iPhone gesendet

Am 26.09.2020 um 02:02 schrieb Viktor Adam [email protected]:

How's triggered different from registered? We just need a list of all the repos that run our hooks, don't we?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[matthijskooijman]

One can also argue that in core.hooksPath mode, githooks has not installed anything into actual repositories (has not even touched them at all), so there is little need for "migrations" in that sense (nothing installed, so nothing to upgrade). However, the example from the big PR already shows this is not necessarily true: the migration that runs per-repo there is about moving local paths from a shared file into git config, which actually migrates things done by the administrator manually, rather than installed by githooks.

However, people might actually be surprised when this migration happens. If I install githooks in hooksPath mode, I might do that so that githooks does not need to touch any of my repositories to do its work. When then during an upgrade githooks suddenly starts changing files in my repository, I could be unpleasantly surprised. That could be a reason to not keep track of any repos "triggered" in hooksPath mode, but just show a notice to the user that things might need migration.

[gabyx]

Jeah, thats a good point, but when we would have the triggered file in place, we are free what we could do: automatic migration or just tell the user, its up for discussion :)

Von meinem iPhone gesendet

Am 26.09.2020 um 19:00 schrieb Matthijs Kooijman [email protected]:

One can also argue that in core.hooksPath mode, githooks has not installed anything into actual repositories (has not even touched them at all), so there is little need for "migrations" in that sense (nothing installed, so nothing to upgrade). However, the example from the big PR already shows this is not necessarily true: the migration that runs per-repo there is about moving local paths from a shared file into git config, which actually migrates things done by the administrator manually, rather than installed by githooks.

However, people might actually be surprised when this migration happens. If I install githooks in hooksPath mode, I might do that so that githooks does not need to touch any of my repositories to do its work. When then during an upgrade githooks suddenly starts changing files in my repository, I could be unpleasantly surprised. That could be a reason to not keep track of any repos "triggered" in hooksPath mode, but just show a notice to the user that things might need migration.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.