On Thu, Oct 08, 2020 at 11:29:34AM -0700, Junio C Hamano wrote: > > Side note: It's a shame that there is no way to convince rev-list not > > to print the "commit ..." header, which is really what we're avoiding > > here. We probably should have suppressed it with user-formats when > > they were introduced, but it's too late to make that change. I wonder > > if it would be worth adding a command-line option, though. I've often > > had to hack around this when parsing rev-list output (and sometimes > > even resort to using git-log if it's a one-off). > > Or make "git log" without frills as fast as rev-list, perhaps? > > What extra things do we do that makes "log" inherently slower than > "rev-list"? It's not the speed of log that is a problem, but just that I usually try to use plumbing when scripting. So I often reach for rev-list first. I do think for just listing commit hashes that log is slower, though. One reason is that when there's a commit-graph, it's not as good at avoiding reading the commit objects. E.g.: $ time git rev-list HEAD >/dev/null real 0m0.031s user 0m0.027s sys 0m0.004s $ time git -c core.commitgraph=false rev-list HEAD >/dev/null real 0m0.362s user 0m0.345s sys 0m0.016s $ time git log --format=%H HEAD >/dev/null real 0m0.371s user 0m0.355s sys 0m0.016s So running "git log" takes about the same time as rev-list if we disable the commit-graph. Which makes sense. The pretty-print code is aggressive about loading the object contents, even if we end up not needing it (because really, everything _except_ userformat does need it, and even userformat usually needs it). I think it would be nice to make the formatting code smarter about reporting exactly which parts it needs. > I do not mind a new option (e.g. --no-header) to "rev-list", though. I took a brief look at this earlier today and it was more awkward than I expected. The "commit <oid>" header might also have other stuff attached to it (revision marks, parents, and who even knew we had a "--timestamp" option?). It's not clear where those things should go if we suppress the header (for oneline, they just get stuck in front of the oneline; would that be OK for userformats, too?). -Peff
