What will happen if I use git pull --rebase ?

git pull --rebase is roughly equivalent to

git fetch
git rebase origin/master

i.e. your remote changes (C) will be applied before the local changes (D), resulting in the following tree

A -- B -- C -- D

What will happen if I use git pull --ff-only ?

It will fail.

git pull --ff-only corresponds to

git fetch
git merge --ff-only origin/master

--ff-only applies the remote changes only if they can be fast-forwarded. From the man:

Refuse to merge and exit with a non-zero status unless the current HEAD is already up-to-date or the merge can be resolved as a fast-forward

Since your local and remote branches have diverged, they cannot be resolved by a fast-forward and git pull --ff-only would fail.

Use ` instead of ' in the database name, and escape the _

GRANT ALL PRIVILEGES ON xian\_%.* TO xian@'192.168.1.%';

Une policy IAM est constituée de statement, ce sont des règles (des blocs de codes)

{
"Statement":[{
"Effect":"effect",
"Action":"action",
"Resource":"arn",
"Condition":{
"condition":{
"key":"value"
}
}
}
]
}

Chaque règle dans sa forme la plus simple est composée de 3 choses :

Effect : allow ou deny

Action : quelle action concerne la règle

Resource : la resource concernée

Chaque service Amazon (EC2, ECR, etc...) expose une liste d'action, on peut trouver cette liste dans la doc (http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Action)

Et chaque resource peut être identifiée par un arn (une manière simple de retrouver un ARN est d'afficher la resources dans l'interface web AWS, il y a souvent l'arn)

J'avais eu les RFC sur ce sujet à commenter pendant le Master, souvenir ahah

:Gdiff
:dp

ça a l'air bien

via Shahor

On peut avoir besoin de faire tourner un ou plusieurs cron dans un environnement Beanstalk composé de X instances
Etant donné que toute les instances sont configurées de la meme manière, si on rajoute le cron dans la config, il sera éxecuté sur toutes les instances

Une solution serait de determiner si on est le "runnner" ou non avant de lancer le cron

Pour que toutes les instances sachent qui est le runner, on peut imaginer un système comme celui ci :

• on interroge l'ELB avec les API pour avoir ses backends
• on trie cette liste de backend
• le runner est le premier de cette liste
• si notre ip est égale à celle du runner, on lance le cron

ça a l'avantage de fonctionner quel que soit le nombre d'instances et ne pas stocker un état (on utilise les infos de l'ELB)

Et si on ne veut pas faire tourner tous les crons sur le runner, on pourrait déterminer runnner1 runnner2 runner3 etc suivant l'ordre et faire tourner certains crons si on est runner1 ou bien runner2

find . ! -user foo -print