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
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
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