Karl Hasselström <kha@xxxxxxxxxxx> writes:
> On 2007-11-28 18:06:36 +0100, Andreas Ericsson wrote:
>
>> True, but there are ways of figuring out which branch you're on,
>> using the arguments passed to the hook.
>>
>> The rebase hook (which is where this discussion started) gets the
>> branches passed to "git rebase" as arguments. Figuring out if either
>> of those branches are actually under stgit control shouldn't be
>> overly tricky for one so familiar with stgit as yourself.
>
> No, that part is trivial. The hard part is not messing up the user's
> existing hook scripts.
>
> If I do go ahead and do this, I have a feeling I'll be beefing up
> git's hook dispatch mechanism first -- if I can get it past Junio,
> obviously. :-)
I do not see a fundamental problem in a scheme like this:
* when running a hook $foo, if .git/hooks/$foo.d/. does not exist, we
operate as we have always done.
* if .git/hooks/$foo.d/ exists, we readdir(3) it and run the hooks found
in the order their names sort bytewise (similar to /etc/rc$n.d/).
- when the purpose of the $foo hook is to return a bool to refuse an
operation, stop at the first failure;
- when the purpose of the $foo hook is to cause effect, run them all
in series.
* When .git/hooks/$foo.d/ exists, there will always be "050-simple" in
that directory. It checks if .git/hooks/$foo exists and sources it
if it does. A custom hook that wants to run before or after it can
be named NNN-mine in .git/hooks/$foo.d/, where NNN sorts earlier or
later than 050 to define the execution order.
We probably would want to reserve a special exit code for the hooks run
for their effects so that they can signal "I do not want you to run the
remainder".
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
