On 2020-12-28 12:47 p.m., Ankit wrote: > Hello > I'm getting used to it. > I'll remove several commits soon, now that I have received the > feedback on the last commit, and will use stricter conditions in the future.
I'd like to replace "stricter conditions" with "well defined/documented conditions" hence the prod to bf-c >> All, > That's a new way of raising concerns on commits. I don't have a concern with "a commit", I have a concern with "The process of how we manage this file", for which bf-committers is an appropriate place. > If I see "cleanup" in the title, the onus is on the committer to make > sure that it really is a cleanup. If that promise is kept. Developers make mistakes and changes can have unforeseen consequences sometimes, as much as we'd all like to write 100% bug free code, guaranteeing it is quite something else. Small changes in structure can sometimes trigger optimizer bugs in compilers, it can be very relevant knowing if even a relatively safe, 100% correct cleanup commit happened to a piece of code. > I don't see why a cleanup commit interests you. A cleanup commit is a commit like any other which can potentially introduce bugs and should be treated as such, hiding it from git blame is counter productive. Now having large quantity of all code blame to a single commit (like e12c08e8d170) yeah that's clearly annoying, and should be remedied but anything beyond that I do not see the benefits of hiding such changes. --Ray _______________________________________________ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
