Thread (9 messages) flat view 9 messages, 6 authors, 2016-06-15

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help