Jeff King venit, vidit, dixit 13.05.2013 13:55: > On Sun, May 12, 2013 at 10:01:38PM -0700, Junio C Hamano wrote: > >> Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: >> >>> Adding to that: >>> >>> Somehow I still feel I should introduce a new attribute "show" (or a >>> better name) similar to "diff" so that you can specifiy a diff driver to >>> use for showing a blob (or grepping it), which may or may not be the >>> same you use for "diff". This would be a much more fine-grained and >>> systematic way of setting a default for "--textconv" for blobs. >>> >>> Of course, some driver attributes would just not matter for coverting >>> blobs, but that doesn't hurt. >>> >>> I'm just wondering whether it's worth the effort and whether I should >>> distinguish between "show" and grep". >> >> Haven't thought things through, but my gut feeling is that it is on >> the other side of the line. We could of course add more features and >> over-engineered mechanisms, and the implementation may end up to be >> even modular and clean, but I cannot answer "Yes" with a confidence >> to the question "Does such a fine grained control help the users?" >> and cannot answer "If so in what way?" myself. > > Yeah, I think the _most_ flexible thing is going to look something like: > > $ cat .gitattributes > *.pdf diff=pdf show=pdf > > $ cat ~/.gitconfig > [diff "pdf"] > textconv = ... > [show "pdf"] > textconv = ... > > But that obviously sucks, because in the common case that you want to > use the same command, you are repeating yourself in the config. You > could assume that the "show" attribute points us at a "diff" block. And > that makes sense for textconv, but what does it mean if you have > "show=foo" and "diff.foo.command" set? I don't propose "show drivers". In your example above, you would point to the same diff driver. If you use a diff driver just with the "show" attribute then only its textconv config will be relevant. But you do have the possibility to use different drivers for diff and show. For example, for showing a file some sort of automatic pagination or line numbering can be helpful whereas it would hurt the diff case. > If the _only_ thing you would want to do with such a "show" mechanism is > to display converted contents on show/grep, then we could lose the > flexibility and say that "show" is a single-bit: do we respect diff > textconv for show/grep in this case, or not? And that leaves only the > question of where to put it: is it a gitattribute, or does it go in the > config? > > I don't think that it is a property of the file itself. That is, you do > not say "foo files are inherently uninteresting to git-show, and > therefore we always convert them, whereas bar files do not have that > property'. You say "in my workflows, I expect to see converted results > from grep/show". And the latter points to using config, like either > "diff.*.showConverted" (to allow per-type setting), or even > "grep.useTextconv" and "show.textConv" (to allow setting it per-user for > all types). I strongly disagree here. I have textconv filters for pdf, gpg, odf, xls, doc, xoj... I know, ugly. At least some of them would benefit from different filteres or different settings. The way I propose it, a user would just have to add "show=foo" to the "diff=foo" lines without having to ad an extra filter, but with the flexibility to do so. > And of course for any workflow-oriented config, you will sometimes want > to override it for a particular operation. But that is why we have a > command-line escape hatch, and that part is already implemented. One may ask what a purely ui output oriented setting like "show" has to do in .gitattributes, of course, but that applies to "diff" as well. Separating the two (one in attributes, one in config) looks artificial to me. Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html