Comment 3 for bug 818206

I'm marking this Wont Fix because I don't think hiding the option would have any affect. Note that from the beginning "apparently recommended to him by somebody". Hiding the flag has no effect on someone telling you to use it. I don't think hiding the flag would help this case.
Not supporting the flag would be an option, but I don't think it is reasonable, given the genuine use case for some people.

As an aside, I did look into turning stacked branches into a cache, and it is really non-trivial. Because then things that are logically read-only start to write. And our transactional repository means you have to define what the transaction boundary is. (start_write_group/commit_write_group, etc.) 'bzr status' doesn't give any hints as to when it will start/stop trying to read more data.

Also note, that even as a cache, we need to watch out for invariants that say if a revision is present, then you have access to its inventory and the texts introduced in that rev. Otherwise you could do 'bzr log -r 1..-1' in a stacked branch, and it would fetch all the revision messages, and if it wanted to insert that into the local repository, it would then need to fetch *all* of the inventories and texts. I'm guessing someone who does 'bzr log' in a stacked branch doesn't intend to fetch the whole repository history.