[Development] Git commit hook keywords

[Laszlo Papp]

>
> In any case, this is why we have reviewers: so they can teach newcomers
> what
> the policies are and how we do things. There will never be documentation
> for
> every single little thing, there's a lot that is latent knowledge.
>

Why would they teach if the newcomers knew after reading the documentation?
The point of documentation is to share the knowledge (i.e. like this one),
isn't it? If nobody does, I will do this later then.


> As I said, it's the "Task-number" that triggers the completion in the
> Gerrit
> UI.
>

How will the "Task-number" entry know whether to jump to Gerrit or Jira? We
need a distinction here because they are separate sources for information.


> But that doesn't explain what QTREVIEW is, why it's misspelt and and why we
> don't need the same for other classes.
>

It is not misspelt. I intentionally wrote QT_REVIEW_ according to the
QT_BUG_ schema. Like I wrote, it could be a better like QTCODEREVIEW or so.
I was just presenting the idea.


>  > People now keep pasting the hard coded link in such situations as far
> as I
> > see which is not clickable right away and hard coded. It would be nice
> if I
> > could write something like "Review-number: QTREVIEW-31541" or something
> > like that.
>
> Paste the permalink of the Gerrit review or the Change-Id, or the bug ID
> with
> "Task-number: " prepended, or a link to the mailing list archives. It
> doesn't
> need to be a link anyway, just an identifier we can look up.
>

Except that, it would be nice to have the entry clickable which redirects
instantly to the gerrit change without any further investigation. Like I
said, just like how it happens in case the QTBUG entry.

Laszlo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120916/5b5aaa52/attachment.html>