Jacob Keller <jacob.keller@xxxxxxxxx> writes: > I agree, "something" is better than "nothing", and we can work to > improve "something" in the future, especially after we get more real > use and see what people think. Only question would be how much do we > need to document the current behavior might be open for improvement? If - it always digs to the root of the history no matter what; and/or - it almost always yields correct but suboptimal result then that fact must be documented in BUGS section, possibly a brief descrition of why that limitation is there, with a hint to invite people to look into fixing it. We should mark it prominently as experimental and advertise it as such. "It's too slow in real project to be usable" and "Its output bases the answer on an irrelevant commit" are not something we want our users to experience, except for those with inclination to (or ability and time to) help improve the feature.
