Junio C Hamano venit, vidit, dixit 23.05.2013 16:40: > Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > >> Didn't you have concerns about storing the context in the object struct? >> I can't quite judge how much of an issue this can be for fsck and such. >> I don't want to increase the memory footprint unnecessarily, of course. > > Yes. I thought I had a weather-balloon patch to fsck to use its own > so that we have something to fall back on if it turns out to be a > problem (and also so that anybody can see how big the difference is), > but I highly suspect that any user of object-array other than what > you are changing in the series wants to use the slim variant, which > suggests that the information does not belong there. > >> Other than that, the mechanism was still up for discussion (separate >> "show" attribute or a config) given that the default behavior for >> showing blobs is not to change. > > My understanding was that the series as-is (not the implementation > but the external interface) makes us honor what the user tells us > better, without changing the behaviour for people who don't instruct > us to do anything differently, so I thought it was a good place to > stop at. > > The 'show attribute or config' discussion would/should involve the > possibility of flipping the default, no? After all, I was getting > the impression, especially from the "config", that this was "If we > had known better when we introduced textconv, we would have defined > it to apply in any situation where you would want a textual form of > a blob, not limited to diff" kind of thing. > > That is a much longer term thing and my impression was that it can > built later on top of the series (once its implementation settles). > > So, yes, thanks for pointing out these two points. The bloat in the > object array element I do care today, the feature and the interface > I do not think we have to worry about them today to hold the series > back. Well, if we decide "showing blobs with textconv is fundamentally different from showing diffs with textconv" then "--textconv" should not apply any textconv filters on blobs unless the user has specified them using a separate attribute (different from "diff"). Therefore, I hesitate introducing the behavior of the current series. For me, it would introduce something of a "mixed beast". I wouldn't hesitate introducing "textconv on by default for blobs the same as for diffs", but that would change existing behavior and the opposition is strong, for a good reason :) So, since that one isn't possible, I'm leaning towards the other extreme: treat the blob and diff case completely separately in the sense that different attributes are used. Then, even with "--textconv" there wouldn't be any blob filtering (show/grep) unless the user specified so using an attribute different from "diff". I'd rather try out the latter before having the "mixed beast" trickle down too much, even both its change in behavior and the one from the attribute version do not show up in daily use until you specify "--textconv" explicitly. 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