Thread (2 messages) 2 messages, 2 authors, 2016-06-15

Re: [PATCH] Make list of features auto-managed.

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:17
Subsystem: the rest · Maintainer: Linus Torvalds

Possibly related (same subject, not in this thread)

I am now getting sort of convinced that the list-features is a
slippery slop towards total suckage, unless managed very
carefully.

The "auto manage" patch I am responding to would tempt anybody
to extend the mechanism to do something like the attached patch,
because a one-line comment near the code, like:

	/* FEATURE<oneline-first-paragraph> */

does not look very useful nor pretty by itself in the source
code.  It makes it very tempting to actually describe the
"feature".  People with only half a brain would even advocate
updating supported_features[] to a tuple of (name, explanation),
and have "git version --list-features" to spit both out, or
something like that.  I really do not think we would want to go
there.

A few years down the road, do we really care if we did not do
something long time ago, but the code was updated and added as a
new feature?  That information belongs to the commit log, not to
in-source comments.  This will lead to the same mistake often
made by users of other SCMs, embedding "$Log$" in their sources.


=== sample diff that is not acceptable ===
diff --git a/commit.c b/commit.c
index dbb28b5..4b713b6 100644
--- a/commit.c
+++ b/commit.c
@@ -1016,6 +1016,12 @@ static void pp_header(enum cmit_fmt fmt,
 	}
 }
 
+/*
+ * FEATURE<oneline-first-paragraph>: we used to treat the first line of the
+ * commit messages special, but messages imported from foreign culture often
+ * have more than one line in the first "paragraph".  We now treat the
+ * first paragraph as special for the purposes of --pretty=oneline.
+ */
 static void pp_title_line(enum cmit_fmt fmt,
 			  const char **msg_p,
 			  unsigned long *len_p,
@@ -1140,6 +1146,11 @@ static void pp_remainder(enum cmit_fmt fmt,
 	}
 }
 
+/*
+ * FEATURE<log-unlimited-message>: we used to have a hard limit
+ * of 16kB message, but that is sometimes not enough for huge commits
+ * imported from foreign culture.  We now dynamically grow the buffer.
+ */
 unsigned long pretty_print_commit(enum cmit_fmt fmt,
 				  const struct commit *commit,
 				  unsigned long len,
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help