Hi Stephan On 18.05.2015 10:39, Stephen Turner wrote: > In my XenCenter dev team at Citrix, we have the policy of requiring a ticket > number on every commit. If we find a bug and there isn't already a ticket, we > create a ticket before committing the fix. I guess I've just dug through > history too many times to understand why something that appears wrong was > done, only to find an inadequate description at the end of the trail.
IMHO understanding why commit x changed is more a problem of the commit message or description. If I pick a random fix commit in the linux kernel, https://github.com/torvalds/linux/commit/5c1ac56b51b9d222ab202dec1ac2f4215346129d you see this small fix and a detailed description, why. Personally I do not like the dependency to network related, centraliced ticket tracking system for understanding code changes of a distributed SCM. But I do see the advantage in seeing what has been reported to be broken and what commit fixes this bug. But the commit description should be fairly detailed, why a commit changed something. However since the changelog for the users is actually not generated from the git log, it makes totally sense to open a ticket before fixing bugs, to get all fixes covered in the changelog. Yours René
signature.asc
Description: OpenPGP digital signature
