On Tue, 29 Jul 2008, Linus Torvalds wrote: > > - But the other huge mistake you make is EVEN MORE STUPID, because it's > so ironic. That magical output you want, and claim is so perfect, and > point out "thus you can still apply as much simplification as you want > on top of it"? You know what? It already _exists_! It's exactly that > --full-history case. Put in other terms: what you ask for can be fairly trivially done as a filter on the _current_ git output (preferably merged into the tool that shows it graphically in the first place), with absolutely no downside. In contrast, if somebody was really so _stupid_ as to go with your output format, then yes, he could further simplify it down to the current default format, but with a huge performance/interactivity downside. See? Your preferred format is not actually the "best" format. Not at all. Quite the reverse. Your preferred format is much better off being a secondary post-processing format exactly because it can be generated from one of the primary formats easily enough. But the reverse isn't true: the current primary formats cannot be generated from your preferred format without losing something important (performance). But I'll make you a deal: if you actually write the filter in C form, I can pretty much guarantee that we can easily add it as a new flag. It really should be pretty easy to integrate it into the revision parsing machinery alongside --topo-order, since it's really the same kind of operation. In fact, it's possible that the current --topo-order sorting could possibly be made to just do the simplification (conditionally, of course, since it has the latency problem). See the function void sort_in_topological_order(struct commit_list ** list, int lifo) in commit.c - that's where it would hook in. 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
