Nikita Karetnikov: > > Using `git blame` or `git log -S` or `git log -G` will actually work > > better than a file by file summary. If you throw in the `-M` option, > > it'll work accross renames, for examples. > > OK. But that information will be lost if we decide to change a VCS for > some reason.
Well, we could avoid switching to a VCS that would loose such valuable information! :) > > Why not put what you wrote in your description email in there? This was > > a good explaination of why the change was actually needed! :) > > >> "GHC was recently changed to not allow you to use newtypes in FFI > >> imports unless the constructor of the newtype is in scope." [1] > >> > >> [1] http://ghc.haskell.org/trac/ghc/ticket/5610 > > OK. So let me summarize: > > 1. I shouldn't explicitly name changed functions or modules. > > 2. I can add a small description (like the above) if it's appropriate. > > Did I forget anything? Feel free to develop your own style and taste. Some readings: http://who-t.blogspot.de/2009/12/on-commit-messages.html http://robots.thoughtbot.com/post/48933156625/5-useful-tips-for-a-better-commit-message http://ablogaboutcode.com/2011/03/23/proper-git-commit-messages-and-an-elegant-git-history/ This is quite thorough: https://wiki.openstack.org/wiki/GitCommitMessages -- Lunar <lu...@torproject.org>
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
