On Mon, Oct 23, 2006 at 10:29:53AM -0700 I heard the voice of Linus Torvalds, and lo! it spake thus: > > I already briought this up once, and I suspect that the bzr people > simply DID NOT UNDERSTAND the question: > > - how do you do the git equivalent of "gitk --all" I for one simply DO NOT UNDERSTAND the question, because I don't know what that is or what I'd be trying to accomplish by doing it. The documentation helpfully tells me that it's something undocumented. > For example, how long does it take to do an arbitrary "undo" (ie > forcing a branch to an earlier state) [...] I don't understand the thrust of this, either. As I understand the operation you're talking about, it doesn't have anything to do with a branch; you'd just be whipping the working tree around to different versions. That should be O(diff) on any modern VCS. > and yes, performance does matter. I agree, and I currently find a number of places bzr doesn't hit the level of performance I think it should. I'm not convinced, however, that any notable proportion of that has to do with the abstract model behind it. And insofar as it has to do with the physical storage model, that can easily be (and I'm confident will be, considering it's a focus) ameliorated with later repository formats. > The whole confusing between "bzr pull" and "bzr merge" is another > _technical_ sign of why branch-local revision numbers are a mistake. I consider it a _technical_ sign of a way of thinking about branches I prefer 8-} -- Matthew Fuller (MF4839) | fullermd@xxxxxxxxxxxxxxx Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html