On 3/22/2012 6:04 AM, Martin Geisler wrote:
This commonly happens when using the bisect command: the tool (Git or Mercurial) will assist you in a binary search for a faulty commit. They update to the middle of the unchecked range and you have to build and test the commit. When doing that, it's annoying if you run into commits that fail because of other problems than the one you're investigating. Such false positives makes automated bisecting impossible.
A perfect example of my assertion that preserving a historical state (to try to avoid tool-centric terminology) can be done for multiple reasons, and that inappropriate detail (inappropriate universally or for a particular task) interferes with the ability to make effective use of the historical record. VCS technology that cleanly distinguishes history appropriate to a particular task would be a great step forward. How to accomplish this -- without adding such a burden to the user (e.g., a long list of tags and annotations, to use the terms generically) that there would be strong motivation to partially or fully subvert the mechanism or its intent and reduces productivity if that temptation is resisted -- I haven't the faintest idea. Policy that forbids preserving states unless they support a particular subset of the possible uses is certainly a practical, useful and sometime strongly advisable solution, but it clearly has the downside of excluding or crippling other uses of the history that may be of value. Topher