On Sun, Jul 11, 2021 at 09:55:10PM +0000, brian m. carlson wrote: > In general, we encourage users to use plumbing commands, like git > rev-list, over porcelain commands, like git log, when scripting. > However, git rev-list has one glaring problem that prevents it from > being used in certain cases: when --pretty is used with a custom format, > it always prints out a line containing "commit" and the object ID. This > makes it unsuitable for many scripting needs, and forces users to use > git log instead. > > While we can't change this behavior for backwards compatibility, we can > add an option to suppress this behavior, so let's do so, and call it > "--no-commit-header". Additionally, add the corresponding positive > option to switch it back on. > > Note that this option doesn't affect the built-in formats, only custom > formats. This is exactly the same behavior as users already have from > git log and is what most users will be used to. Thanks for working on this. It has bugged me for at least a decade. :) I do wish this had been made the default when we introduced --pretty=format, but I agree we can't just change it now. This could be something to keep in mind for future deprecation (or a large breaking version). People would have to start saying --commit-header now to future-proof themselves if they really want the current behavior. I'm OK to leave any plans / warnings like that for future work. The patch looks correct to me. I did have one small nit: > diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt > index 5bf2a85f69..23388f36c3 100644 > --- a/Documentation/rev-list-options.txt > +++ b/Documentation/rev-list-options.txt > @@ -1064,6 +1064,14 @@ ifdef::git-rev-list[] > --header:: > Print the contents of the commit in raw-format; each record is > separated with a NUL character. > + > +--no-commit-header:: > + Suppress the header line containing "commit" and the object ID printed before > + the specified format. This has no effect on the built-in formats; only custom > + formats are affected. It wasn't immediately obvious to me what "custom formats" meant here. I don't think we use that term elsewhere, nor do we seem to have a succinct phrase for the concept. Maybe something like: only custom formats (i.e., `--pretty=format:`) are affected. helps without making it too clunky? -Peff
