Hook : Sort all hooks following an human listing #755

New Issue

GiteaMirror · 2025-11-02T03:35:15-06:00

GiteaMirror commented

2025-11-02 03:35:15 -06:00

Originally created by @camlafit on GitHub (May 29, 2017).

Gitea execute hook following a glob listing, in some case this list could be not adapted. Mainly if a hook required to be execute at specific step.

Prefer a $(ls -1 |sort -h) looks useful.

Then with this list : 01-erere ezaezae 02-erezrze 1-zerezr 10-erezrze 2-erezrze 99-ererer

we obtain actually :
01-erere
02-erezrze
10-erezr
1-zerezr
2-erezrze
99-ererer
ezaezae

As we can see 10 is previous 1

Should be better to get this result :
ezaezae
01-erere
1-zerezr
02-erezrze
2-erezrze
10-erezrze
99-ererer

Originally created by @camlafit on GitHub (May 29, 2017). Gitea execute hook following a glob listing, in some case this list could be not adapted. Mainly if a hook required to be execute at specific step. Prefer a ```$(ls -1 |sort -h)``` looks useful. Then with this list : _01-erere ezaezae 02-erezrze 1-zerezr 10-erezrze 2-erezrze 99-ererer_ we obtain actually : 01-erere 02-erezrze 10-erezr 1-zerezr 2-erezrze 99-ererer ezaezae As we can see 10 is previous 1 Should be better to get this result : ezaezae 01-erere 1-zerezr 02-erezrze 2-erezrze 10-erezrze 99-ererer

GiteaMirror added the type/proposal type/feature labels 2025-11-02 03:35:15 -06:00

GiteaMirror closed this issue

2025-11-02 03:35:15 -06:00

GiteaMirror commented

2025-11-02 03:35:16 -06:00

@bkcsoft commented on GitHub (Jun 11, 2017):

This is standard .d behaviour. I don't see how this would be useful TBH :/

Edit: If you need them to be executed in a specific order just prefix them with NN- (where N is a digit)

@bkcsoft commented on GitHub (Jun 11, 2017): This is standard `.d` behaviour. I don't see how this would be useful TBH :/ Edit: If you _need_ them to be executed in a specific order just prefix them with `NN-` (where N is a digit)

GiteaMirror commented

2025-11-02 03:35:16 -06:00

@camlafit commented on GitHub (Jun 11, 2017):

Hi

I've forgotten to provide a sample, I've an use case with subgit (hook
system to translate git<->svn)

I would also like to point to one thing: in pre-receive.d/ it would be
better if a symlink to SubGit hook would be called the last, so maybe it's
worth renaming the hooks to
start with numbers if Gitea respects names order:

pre-receive.d/
00-hook1
01-hook2
...
99-symlink-to-subgit-hook

This is because SubGit could translate something to SVN but if there were
a hook running after SubGit hook, this hook could reject the whole push. As
result there would be
a corresponding commit in SVN while "git push" command would fail (and
then SubGit will translate this new SVN revision back to Git and the result
will be as if that later
hook didn't fail at all). It's not a big problem but just a strange
behaviour. E.g.this would be especially strange if the hook running after
SubGit hook would control access to
this or that branch, because its result would be completely ignored. We
had this problem with Gitolite and for it we recommended to make sure Git
hooks are called the last.

@camlafit commented on GitHub (Jun 11, 2017): Hi I've forgotten to provide a sample, I've an use case with subgit (hook system to translate git<->svn) > I would also like to point to one thing: in pre-receive.d/ it would be > better if a symlink to SubGit hook would be called the last, so maybe it's > worth renaming the hooks to > start with numbers if Gitea respects names order: > > pre-receive.d/ > 00-hook1 > 01-hook2 > ... > 99-symlink-to-subgit-hook > > >This is because SubGit could translate something to SVN but if there were > a hook running after SubGit hook, this hook could reject the whole push. As > result there would be > a corresponding commit in SVN while "git push" command would fail (and > then SubGit will translate this new SVN revision back to Git and the result > will be as if that later > hook didn't fail at all). It's not a big problem but just a strange > behaviour. E.g.this would be especially strange if the hook running after > SubGit hook would control access to > this or that branch, because its result would be completely ignored. We > had this problem with Gitolite and for it we recommended to make sure Git > hooks are called the last.

GiteaMirror commented

2025-11-02 03:35:16 -06:00

@camlafit commented on GitHub (Jun 11, 2017):

As said on mine examples, NN prefix is not relevant we can have 10 before 1
Why ls with sort could be solve this behavior

@camlafit commented on GitHub (Jun 11, 2017): As said on mine examples, NN prefix is not relevant we can have 10 before 1 Why ls with sort could be solve this behavior

GiteaMirror commented

2025-11-02 03:35:16 -06:00

@bkcsoft commented on GitHub (Jun 15, 2017):

NN prefix works just fine, 01_ is listed before 10_ 🙂

@bkcsoft commented on GitHub (Jun 15, 2017): NN prefix works just fine, `01_` is listed before `10_` 🙂

GiteaMirror commented

2025-11-02 03:35:16 -06:00

@camlafit commented on GitHub (Jun 15, 2017):

but could be better to have a predictable sort without considerate separator :)
And if I've understood related patch should be small

@camlafit commented on GitHub (Jun 15, 2017): but could be better to have a predictable sort without considerate separator :) And if I've understood related patch should be small

GiteaMirror commented

2025-11-02 03:35:17 -06:00

@bkcsoft commented on GitHub (Jun 19, 2017):

But it is predictable. This is literaly how every single conf.d implementation works 😕

@bkcsoft commented on GitHub (Jun 19, 2017): But it is predictable. This is literaly how every single `conf.d` implementation works 😕

GiteaMirror commented

2025-11-02 03:35:17 -06:00

@camlafit commented on GitHub (Jun 19, 2017):

Hi

Ok as won't be changed, maybe should be better to provide a documentation
about hooks behavior and naming

@camlafit commented on GitHub (Jun 19, 2017): Hi Ok as won't be changed, maybe should be better to provide a documentation about hooks behavior and naming

GiteaMirror commented

2025-11-02 03:35:17 -06:00

@bkcsoft commented on GitHub (Jun 19, 2017):

That does however make sense :)

@bkcsoft commented on GitHub (Jun 19, 2017): That does however make sense :)

GiteaMirror commented

2025-11-02 03:35:17 -06:00

@warnat commented on GitHub (Sep 12, 2020):

can this be closed now, to get gitea forward, please?

@warnat commented on GitHub (Sep 12, 2020): can this be closed now, to get gitea forward, please?

GiteaMirror referenced this issue

2025-11-02 11:49:22 -06:00