Re: commit summary, --pretty=short and other tools
From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:43:35
Hi, On Tue, 18 Sep 2007, Benoit SIGOURE wrote:
On Sep 18, 2007, at 12:13 PM, Johannes Schindelin wrote:quoted
On Tue, 18 Sep 2007, Andreas Ericsson wrote:quoted
const char *find_commit_subject_end(const char *commit_msg) { const char *dot, *paragraph_end; paragraph_end = strstr(commit_msg, "\n\n"); dot = strchr(commit_msg, '.'); return min_non_null(dot, paragraph_end); } would probably get it right very nearly always.Counterexample (not even mentioning the missing handling of NULL): http://brick.kernel.dk/git/?p=qemu.git;a=commit;h=eb66d86e295cd5a8f13221589806e15db62a62fa And no, the responsible developer showed a strong unwillingness to adapt to better tools and workflows.OK, look, I think this is the typical case where there is no single solution to fit all use cases. To handle this specific case, you could say "OK let's stop at punctuation symbols then". But what if my commit message is "Add namespace::member whatever." If there is a single line followed by a blank line: it's a git-style commit message, do what was done before.
That's the current behaviour already. And has been for a long time.
Otherwise, we need some heuristic to find the relevant part of the commit message (if there is such a relevant part in the first place!).
Or do we? I was opposed to this change, since I think that there is really no way to fit all exisiting (!) repositories. And since oneline was always only meant as a hint, it might just as well have stayed at "just one line, the first one". Maybe you guys find a better method, such as providing a regular expression in the config or something, but let's not do another change that does not work for all cases. Ciao, Dscho