Re: Pourquoi du théorie des patch c'est bien

Je rebondis sur mon (y a même des chances que ça ne compile juste pas) avec un exemple.

Supposons que j'ai sur master cette méthode en Groovy pour récupérer un utilisateur dans mon appli Grails, qui filtre les utilisateurs blacklistés (on passera sur la propreté d'utiliser des null, de ne pas filtrer directement en base, etc., hein, c'est un exemple) :

def getUser(String login) {
 def user = User.findByLogin(login)
 if (user.blacklisted) return null
 return user
}

Dans la branche A le développeur gentil décide que le blacklist c'est trop méchant et retire ce filtre :

def getUser(String login) {
 def user = User.findByLogin(login)
 return user
}

Plus tard, dans la branche B le développeur méchant pense que le blacklist c'est cool et qu'en plus un type qui ne s'est pas connecté depuis 1 mois c'est louche :

def getUser(String login) {
 def user = User.findByLogin(login)
 if (user.blacklisted) return null
 else if (user.lastAccess < DateTime.now.minusMonths(1)) return null
 return user
}

Qu'est-ce que pijul va faire au merge ? S'il applique les patchs successivement le résultat ne compilera même pas avec un else orphelin :

def getUser(String login) {
 def user = User.findByLogin(login)
 else if (user.lastAccess < DateTime.now.minusMonths(1)) return null
 return user
}

Toute autre combinaison valide syntaxiquement (retirer les deux test, garder les deux) est indécidable sans les specs de l'appli. Ainsi que toute modification (genre retirer le premier filtre mais garder celui sur la date en retirant le else, comment tu sais que c'est ce qu'on veut finalement ? Et pijul ne parle pas le Groovy à priori).

À moins que j'ai vraiment loupé un truc, seule l'attitude de git, s'arrêter et te dire t'es gentil tu corriges tes conneries est valide.