Junio C Hamano wrote:
> Felipe Contreras <felipe.contre...@gmail.com> writes:
> > ... there are _already_ hooks without pre/post.
> Like commit-msg? Yes, it would have been nicer if it were named
> verify-commit-message or something.
No it wouldn't. I can use the commit-msg hook to change the commit message and
to absolutely no verification, so verify-commit-message would be misleading.
Maybe you would like modify-and-or-verify-commit-message which would be
correct, but I wouldn't, I like short-and-sweet, and commit-msg is just that.
> Old mistakes are harder to change because of inertia. It is not a
> good excuse to knowingly make a new mistake to add new exceptions
> that the users need to check documentations for, is it?
That's a nifty trick; label something a mistake, and then it suddenly becomes
No, it's not a mistake, first it has to be proven to be mistake and I haven't
seen any arguments that try to do so.
Besides it's a red herring, you said such a name would be original and I've
just proved that it's not original, so the originality is not a concern.
> > And it's not confusing,
> A simple fact that Ilya asked the question tells us otherwise ;-)
It's not any more confusing than these:
When does this happen? Can I return an error?
Again when does it happen? What does the input contains? The whole patch?
Including the message?
What is the difference between these? Doesn't pre-commit contains the message
Before receiving what?
Updating what? When is it called? Can I cancel something?
The fact that somebody asked a question doesn't make a name confusing.
> I personally do not see an immediate need for post-update-branch,
> but if the new hook is about intervening an operation,
It's not about that, I can remove that feature if it would make you happier.
> Otherwise it would be impossible to later add "post-update-branch"
Which is never going to happen.
I'm still waiting for anybody to imagine any reason why we might want
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html