Hey, As long as nobody messes with the branch, it doesn't. Just like using a > variable > instead of a constant doesn't cause problems... until it does. >
Do you object against trying this approach and seeing if troubles actually occur? Also keep in mind that tags are not set in stone. You can update them. And unlike with constants in programming languages, that really should not be changed, and to which change would be hard to detect, git has this nice history feature. And who is to say we never want to update the demo thing? We never run into situations where we tag and then figure that one commit we wanted in was not there yet, and thus need to re-tag? Using branches as proposed will fix a concrete problem - as with almost any type of change, there is potential for unintended effects, and there are trade-offs. In a case so trivial as this, we can just switch back if problems occur. In fact, I'm quite certain we already spend more time discussing this now then we would have dealing with an hypothetical unacceptable problem and making the switch back. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --
_______________________________________________ Wikidata-tech mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
