Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>> >> I have a branch which should always be recompiled on update;
>> >> post-update-branch would be a good place for that.
>> >
>> > And why would pre-update-branch not serve that purpose?
>>
>> Because the code that needs to be compiled is not yet in the workspace
>
> And it won't be in 'post-update-branch' either.
>
> % git checkout master
> % git branch feature-a stable
> <- update-branch hook will be called here
>
> The hook will get 'feature-a' as the first argument, but the code in the
> workspace would correspond to 'master'; the checked out branch (pre or post).
The whole point of a pre- hook is to run _before_ the externally
observable state changes due to the operation.
If Stephen has a separate build-tree that fetches from the branch
every time the tip of the branch changes in this repository to
produce build artifacts for the branch to be shared in his network,
perhaps via NFS or something. "git fetch" that will be run from
that build-tree repository will *not* see the tip of the branch, and
running such a hook will not be possible from a pre-update-branch
hook.
We can certainly argue that such a hook could instead push to the
build-tree repository using the commit object name, but I tend to
think such an argument is merely sidestepping the real issue. Some
hooks do want to observe the state _after_ the operation [*1*],
while some hooks can do without seeing exactly the state after the
operation.
So while I am generally not very supportive towards post-anything
hook, I would reject a claim that says "pre-anything can be used
without inventing post-anything---do the same thing and allow the
operation and you are done". That is not simply true.
[Footnote]
*1* A trivial example: send out an e-mail that contains the output
from "git branch -l -v" or "git log --oneline --decorate --all"
to a logger and expect to see the branch tip pointing at the
commit _after_ the operation.
--
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