Hi, the baroque usage options of both git-log and git-rev-list make them pretty much equivalent as far as I can see, except that: * Both have slightly different options set * git log --pretty=format is actually sane and does not pollute the output with spurious 'commit' lines * I assume there are more subtle behaviour differences I think that having two commands that by now do essentially the same thing, but slightly differently, is rather messy UI. Thus, I'm wondering if it would be worthwhile to make rev-list a thin git-log wrapper and start phasing it out? Yes, git-rev-list is supposed to be a plumbing thing, but from my porcelain, I actually have to use git-log anyway if I'm to avoid messing up my code with workarounds to the --pretty=format commit lines evilness (hey, if I'm using --pretty=format, it means I actually want to _control_ rev-list output, not having it trying to outsmart me anyway). Merging porcelain and plumbing interface in a single command may sound like a bad idea UI-wise, but I believe that consolidation would actually result in a UI _improvement_ - you can cleanly separate the documentation to the porcelain and plumbing part (actually, maybe pushing all the plumbing part like --pretty documentation to git-log-plumbing(1), having actually user-relevant options like -p or --no-meges in git-log(1)). And you do not have to tell the user "oh, and there is also git-rev-list(1) which does the same thing, but differently; ah, and for some reason you are also to use only that one if you need to query for bisect points". Should I do it? -- Petr "Pasky" Baudis Whatever you can do, or dream you can, begin it. Boldness has genius, power, and magic in it. -- J. W. von Goethe -- 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
