On 06.10.2013 22:12, Julian Foad wrote: > Gabriela Gibson wrote: > >> The following conversation took place on the svn-dev IRC yesterday >> evening, with Eitan Adler: >> >> <Eitan> feature request: "svn commit --unimportant" which does >> not destroy "svn blame" unless you write "svn blame --all" >> <cinnamon> Eitan: what were you trying to do that made you think >> of this? >> <Eitan> cinnamon: fix up whitespace errors >> <Eitan> cinnamon: the idea is similar to wikipedia's "trivial edit" >> <Eitan> cinnamon: I'd love to go en mass through our code and >> fix up internal whitespace errors but that would destroy "svn blame" >> of who wrote what >> <cinnamon> nod, that would defeat the purpose of blame somewhat >> <lgo> you can of course use the ignore white space option for blame >> <Eitan> lgo: in some cases it isn't just whitespace >> <Eitan> for example, in our documentation we use >> "&os;" instead of "FreeBSD" >> <Eitan> and I'd love to be able to change all the latter to >> the former >> <Eitan> etc. etc. etc. >> <Eitan> cinnamon: that is why I propose "blame" and >> "blame --include-everything/" >> >> I think this would be a very useful addition for many users and so >> that it does not get lost in the IRC chat, I thought I post it here >> for discussion. > I would like to suggest a different approach to this kind of task. > > The 'log' command was recently given a 'search' option by Stefan Sperling. > In v1.8, 'svn log --search=foo' displays only revisions where the log message > contains 'foo' or the author contains 'foo' or the list of changed paths > contains 'foo' or the date contains 'foo'. > > A similar option to 'blame' would make sense. The use case is that you want > the blame to ignore all the revisions where the change was 'whitespace only' > or 'cosmetic' or 'comments only' or 'the change that user X made in revision > Y' or some such condition. I think it makes sense to use exactly the same > mechanism that allows us to specify which revisions 'log' should show, to > control which revisions 'blame' should show. > > Of course, as well as allowing the 'search' option to be used in > 'blame', we might also want to extend its capabilities, for example to > have a negative form (revisions that do not match 'cosmetic'), or to be > able to search for a rev-prop (revisions that do not contain a rev-prop > named 'trivial-change') etc. > > For example, if you wanted to tag a commit as being trivial, you could put > the text '[trivial]' in the log message, and then you could use "svn blame > --search-not='[trivial]'" to only show non-trivial revisions. > > I think that sharing and extending an existing capability like 'search' makes > a lot more sense than adding a specific switch to tag commits for one purpose > (how would it tag them? with a revision property?) and another specific > switch to ignore the specifically tagged commits.
I agree. Filtering should be a decision made by whoever invokes "blame", not by the committer. The author of a commit shouldn't presume to know what someone wants to know about his commit, or even what kind of repository history analysis tools may be available in the future. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
