Tyler Romeo <tylerro...@gmail.com> wrote: > That's my point. You wouldn't use "Fixes: 123" if it doesn't actually fix > bug 123. However, what if there's a case like I said, where a bug is fixed > across multiple commits. If you're using the "Fixes" tag, then technically > you should only be tagging the last commit that finally fixes the bug, in > which case all the other commits are left unmarked and are lost in the > repository. With just a "Bug" tag, it indicates that the commit is related > to the bug.
Then use "Relates-To:" for the relationships, and "Fixes:" for the fixes. > My reasoning has to do with the motivation behind why we tag commits. Maybe > I'm wrong, but the reason we tag commits with bug numbers is so that, in > the future, if one wants to find the commit(s) that fixed a certain bug, > they can do a quick grep search on the commit log and find the relevant > commits. > [...] I don't agree with that. There are lots of bugs that get fixed unknowingly because most of the 5034 bugs are not on the developers' radar. So any (consistent) information on which commit has fixed a bug must be kept in Bugzilla as we can't change Git's history, and it's hard to imagine a case where you want to know which commit(s) fixed bug x without looking at Bugzilla's page on bug x. IMHO the primary motivation for using "Fixes: 123" (or "Relates-To: 123") is to absolve the committer from te- diously going back to the Bugzilla page and adding a Gerrit link and (in the former case) the merger from marking the bug as resolved as computers are so *much* better at that (and cheaper). Tim _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
