>> The idea was to make that "10" a preference value, and to change the
>> tools like "History" to respect the preference.  Because usually we
>> don't need to look back more than 10 versions, but when we did it'd
>> retrieve it automatically, dynamically, silently.
>
> Nice idea in general though I'm not often a fan of the 'silent' bit. And especially not a fan of the 'unasked massive file loading' aspect.
Replacing the ancestry with a stub that can fetch the rest of the
history is an excellent idea but how about making it ask the user
first? It may well be inconvenient or even impossible to fetch the
files, for example. I can see that there might be places where
allowing the user to prevent loading something might cause other
problems, but surely catching those cases would be preferable to
getting the error from a failed network probe?

You want to have a 100% guaranteed interruption prompt box to avoid a
_possible_ network error box 1% of the time?

What is the scenario that has you wanting to stub ancestry and then
get it back in the first place?  In my world, the only use-case I can
think for that is "debugging in production".  I'm in one of my
production images which had been previously "shrunk", and sometimes
viewing change-history is a useful part of debugging.  But if I'm in
the production image then I've got network access so, no problem..?