M .bugs/bugs +1 -0
@@ 1,3 1,4 @@
+Allow repository-specific details template file | owner:, open:True, id:01d5e871a981b06fa08e1c44d792c40d53d68d34, time:1350784692.88
Should output prefix of newly added bug if possible | owner:Michael, open:False, id:1364b6de76f3b532867da63223a45d429ba08a46, time:1277687762.41
New version testing collides with old b.version string | owner:Michael, open:True, id:16d8ee7f1e369472542ac9cebecf2b113dfbaf23, time:1335967376.96
Add support for hg b list --template TEMPLATE | owner:, open:True, id:199de31487e43b849f026b2b813d3a2989088e30, time:1350779494.93
A => .bugs/details/01d5e871a981b06fa08e1c44d792c40d53d68d34.txt +21 -0
@@ 0,0 1,21 @@
+# Lines starting with '#' and sections without content
+# are not displayed by a call to 'details'
+#
+[details]
+Currently, when you run "hg b edit" for a bug that doesn't yet have a details
+file, it creates a new file based on a static template hardcoded within the
+extension's implementation. While that can remain the default behavior, I'm
+sure that in some cases, an alternate template would be desirable. I propose
+that if a "newdetails.txt" file exists in the bugsdir, its contents will be
+used as the template instead of the default. This allows customizations such
+as addition/removal of sections, additions/removal of comments, or even trivial
+changes such as addition of a trailing newline.
+
+Instead of hardcoding the path "newdetails.txt", it could be a default as well.
+The addition of a bugs.newdetails configuration option, interpreted as a path
+relative to the bugsdir would allow users control over the structure of the
+directory, or possibly overriding the default for a repository by specifying
+an alternate path or absolute path.
+
+[comments]
+# Comments and updates - leave your name