Michael J Gruber <g...@drmicha.warpmail.net> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
