On Mon, 23 Oct 2006, Matthew D. Fuller wrote: > 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. gitk (and all other logging functions) can take as its argument a set of arbitrary revision expressions. That means, for example, that you can give it a list of branches and tags, and it will generate the combined log for all of them. "--all" is just shorthand for that, but it's really just a special case of the generic facility. This is _invaluable_ when you want to actually look at how the branches are related. The whole _point_ of having branches is that they tend to have common state. For example, let's say that you have a branch called "development", and a branch called "experimental", and a branch called "mainline". Now, _obviously_ all of these are related, but if you want to see how, what would you do? In git, one natural thing would be, for example, to do gitk development experimental ^mainline (where instead of "gitk" you can use any of the history listing things - gitk is just the visually more clear one) which will show you what exists in the branches "development" and "experimental", but it will _subtract_ out anything in "mainline" (which is sensible - you may want to see _just_ the stuff that is getting worked on - and the stuff in mainline is thus uninteresting). See? When you visualize multiple branches together, HAVING PER-BRANCH REVISION NUMBERS IS INSANE! Yet, clearly, it's a valid and interesting operation to do. An equally interesting thing to ask is: I've got two branches, show me the differences between them, but not the stuff in common. Again, very simple. In git, you'd literally just write gitk a...b (where "..." is "symmetric difference"). Or, if you want to see what is in "a" but _not_ in "b", you'd do gitk b..a (now ".." is regular set difference, and the above is really identical to the "a ^b" syntax). And trust me, these are all very valid things to do, even though you're talking about different branches. Try it out. > > 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. No. If you "undo", you'd undo the whole history too. And if you undo to a point that was on a branch, you'd have to re-write _all_ the revision ID's. > I consider it a _technical_ sign of a way of thinking about branches I > prefer 8-} Quite frankly, I just don't think you understand what it means. Linus - 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