Attention : la vidéo linkée au sujet du Brexit, je m'en fiche !

La raison de mon poste est le message ajouté par Youtube en-dessous de la vidéo (je suppose à la demande de la mafia au gouvernement) et qui dit la chose suivante :

RT est financée entièrement ou partiellement par le gouvernement russe. Wikipedia

Vous aurez sans aucun doute remarqué le niveau de mauvaise foi astronomique, car sous les vidéos de FranceTV, TF1 et autre BullshitFMTV, il n'y a pas de message indiquant que TOUTES CES CHAÎNES SONT FINANCÉES "entièrement ou partiellement" PAR LE GOUVERNEMENT FRANÇAIS ! (via des "aides" ou via un petit chèque de 450 millions d'euros pour FranceTV).

Et oui, cela s'appelle de la propagande ! Et notre chère mafia la distille dans l'esprit des gens afin qu'ils croient que des vilains-méchants-russes financent des organes attaquant notre bel état français, qui rappelons-le est incorruptible, loyale et juste, alors que le gouvernement français n'a fait, ne fait et ne fera jamais la même chose avec sa presse, ses chaînes de radio et de télévision...

Un hastag me vient à l'esprit : #ImmondesBatards allez savoir pourquoi ?

@Lenny qu'en penses-tu ?

Writing Good Commit Messages

Rule zero: “good” is defined by the standards of the project you're on. Have a look at what the existing messages look like, and try to emulate that first before doing anything else.

Having said that, here are some things that will help your commit messages be useful later:

Treat the first line of the message as a one-sentence summary. Most SCM systems have an “overview” command that shows shortened commit messages in bulk, so making the very beginning of the message meaningful helps make those modes more useful for finding specific commits. It's okay for this to be a “what” description if the rest of the message is a “why” description.

Fill out the rest of the message with prose outlining why you made the change. The guidelines for a good “why” message are the same as the guidelines for good comments, but commit messages can be signifigantly longer. Don't bother reiterating the contents of the change in detail; anyone who needs that can read the diff themselves.

If you use an issue tracker (and you should), include whatever issue-linking notes it supports right at the start of the message, where it'll be visible even in shortlogs. If your tracker has absurdly long issue-linking syntax, or doesn't support issue links in commits at all, include a short issue identifier at the front of the message and put the long part somewhere out of the way, such as on a line of its own at the end of the message.

Pick a tense and a mood and stick with them. Reading one commit with a present-tense imperative message (“Add support for PNGs”) and another commit with a past-tense narrative message (“Fixed bug in PNG support”) is distracting.

If you need rich commit messages (links, lists, and so on), pick one markup language and stick with it. It'll be easier to write useful commit formatters if you only have to deal with one syntax, rather than four. (Personally, I use Markdown on projects I control.)
    This also applies to line-wrapping: either hard-wrap everywhere, or hard-wrap nowhere.

An Example

commit 842e6c5f41f6387781fcc84b59fac194f52990c7
Author: Owen Jacobson owen.jacobson@grimoire.ca
Date: Fri Feb 1 16:51:31 2013 -0500

DS-37: Add support for privileges, and create a default privileged user.

This change gives each user a (possibly empty) set of privileges. Privileges
are mediated by roles in the following ways:

* Each user is a member of zero or more roles.
* Each role implies membership in zero or more roles. If role A implies role
  B, then a member of role A is also a transitive member of role B. This
  relationship is transitive: if A implies B and B implies C, then A implies
  C. This graph should not be cyclic, but it's harmless if it is.
* Each role grants zero or more privileges.

A user's privileges are the union of all privileges of all roles the user is a
member of, either directly or transitively.

Obviously, a role that implies no other roles and grants no priveleges is
meaningless to the authorization system. This may be useful for "advisory"
roles meant for human consumption.

This also introduces a user with the semi-magical name '*admin' (chosen
because asterisks cannot collide with player-chosen usernames), and the group
'*superuser' that is intended to hold all privileges. No privileges are yet
defined.

Tellement moins drôle mais tellement plus vrai.

D'autant que çà te prendra 15 minutes à tout péter à y transférer les fichiers qui vont bien et je peux te filer un coup de main pour la configuration HTTPS.

Chlouchloutte... même question ?