[PATCH] Add `log.decorate' configuration variable.

[PATCH] Add `log.decorate' configuration variable.

[Steven Drake]

This alows the 'git-log --decorate' to be enabled by default so that normal
log outout contains ant ref names of commits that are shown.

Signed-off-by: Steven Drake <sdrake@xnet.co.nz>
---
 Documentation/config.txt |    7 +++++++
 builtin-log.c            |    9 ++++++++-
 2 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1aead58..8359eb5 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1217,6 +1217,13 @@ log.date::
 	following alternatives: {relative,local,default,iso,rfc,short}.
 	See linkgit:git-log[1].
 
+log.decorate::
+	Print out the ref names of any commits that are shown by the log
+	command. If 'short' is specified, the ref name prefixes 'refs/heads/',
+	'refs/tags/' and 'refs/remotes/' will not be printed. If 'full' is
+	specified, the full ref name (including prefix) will be printed.
+	This is the same as the log commands '--decorate' option.
+
 log.showroot::
 	If true, the initial commit will be shown as a big creation event.
 	This is equivalent to a diff against an empty tree.
diff --git a/builtin-log.c b/builtin-log.c
index 89f8d60..cd6158c 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -24,6 +24,7 @@
 static const char *default_date_mode = NULL;
 
 static int default_show_root = 1;
+static int decoration_style = 0;
 static const char *fmt_patch_subject_prefix = "PATCH";
 static const char *fmt_pretty;
 
@@ -35,7 +36,6 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
 		      struct rev_info *rev)
 {
 	int i;
-	int decoration_style = 0;
 
 	rev->abbrev = DEFAULT_ABBREV;
 	rev->commit_format = CMIT_FMT_DEFAULT;
@@ -249,6 +249,13 @@ static int git_log_config(const char *var, const char *value, void *cb)
 		return git_config_string(&fmt_patch_subject_prefix, var, value);
 	if (!strcmp(var, "log.date"))
 		return git_config_string(&default_date_mode, var, value);
+	if (!strcmp(var, "log.decorate")) {
+		if (!strcmp(value, "full"))
+			decoration_style = DECORATE_FULL_REFS;
+		else if (!strcmp(value, "short"))
+			decoration_style = DECORATE_SHORT_REFS;
+		return 0;
+	}
 	if (!strcmp(var, "log.showroot")) {
 		default_show_root = git_config_bool(var, value);
 		return 0;
-- 
1.6.6

Re: [PATCH] Add `log.decorate' configuration variable.

[Junio C Hamano]

Steven Drake <sdrake@xnet.co.nz> writes:

> This alows the 'git-log --decorate' to be enabled by default so that normal
> log outout contains ant ref names of commits that are shown.
>
> Signed-off-by: Steven Drake <sdrake@xnet.co.nz>
> ---

Thanks.

This needs some test to make sure that it triggers when configuration is
set, it doesn't when configuration is not set, and it doesn't for commands
in log family when it shouldn't (most notably, format-patch).

> +log.decorate::
> +	Print out the ref names of any commits that are shown by the log
> +	command. If 'short' is specified, the ref name prefixes 'refs/heads/',
> +	'refs/tags/' and 'refs/remotes/' will not be printed. If 'full' is
> +	specified, the full ref name (including prefix) will be printed.
> +	This is the same as the log commands '--decorate' option.

This should be the same as --decorate option, so it should be possible to
set it as a boolean true to mean "short", i.e.

	[log]
        	decorate
		decorate = true

should be treated exactly the same way as

	[log]
        	decorate = short

> diff --git a/builtin-log.c b/builtin-log.c
> index 89f8d60..cd6158c 100644
> --- a/builtin-log.c
> +++ b/builtin-log.c
> @@ -249,6 +249,13 @@ static int git_log_config(const char *var, const char *value, void *cb)
>  		return git_config_string(&fmt_patch_subject_prefix, var, value);
>  	if (!strcmp(var, "log.date"))
>  		return git_config_string(&default_date_mode, var, value);
> +	if (!strcmp(var, "log.decorate")) {
> +		if (!strcmp(value, "full"))
> +			decoration_style = DECORATE_FULL_REFS;
> +		else if (!strcmp(value, "short"))
> +			decoration_style = DECORATE_SHORT_REFS;
> +		return 0;

Hence you need to be prepared to see (value == NULL) here without
segfaulting.  Perhaps something like this patch on top of yours.

 cache.h       |    1 +
 config.c      |   12 +++++++++---
 builtin-log.c |   11 +++++++++++
 3 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/cache.h b/cache.h
index d478eff..24addea 100644
--- a/cache.h
+++ b/cache.h
@@ -923,6 +923,7 @@ extern int git_parse_ulong(const char *, unsigned long *);
 extern int git_config_int(const char *, const char *);
 extern unsigned long git_config_ulong(const char *, const char *);
 extern int git_config_bool_or_int(const char *, const char *, int *);
+extern int git_config_maybe_bool(const char *, const char *);
 extern int git_config_bool(const char *, const char *);
 extern int git_config_string(const char **, const char *, const char *);
 extern int git_config_pathname(const char **, const char *, const char *);
diff --git a/config.c b/config.c
index 6963fbe..6642d30 100644
--- a/config.c
+++ b/config.c
@@ -322,9 +322,8 @@ unsigned long git_config_ulong(const char *name, const char *value)
 	return ret;
 }
 
-int git_config_bool_or_int(const char *name, const char *value, int *is_bool)
+int git_config_maybe_bool(const char *name, const char *value)
 {
-	*is_bool = 1;
 	if (!value)
 		return 1;
 	if (!*value)
@@ -333,7 +332,14 @@ int git_config_bool_or_int(const char *name, const char *value, int *is_bool)
 		return 1;
 	if (!strcasecmp(value, "false") || !strcasecmp(value, "no") || !strcasecmp(value, "off"))
 		return 0;
-	*is_bool = 0;
+	return -1;
+}
+
+int git_config_bool_or_int(const char *name, const char *value, int *is_bool)
+{
+	int v = git_config_maybe_bool(name, value);
+	if (0 <= v)
+		return v;
 	return git_config_int(name, value);
 }
 
diff --git a/builtin-log.c b/builtin-log.c
index 3100dc0..23c00f0 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -253,6 +253,16 @@ static int git_log_config(const char *var, const char *value, void *cb)
 	if (!strcmp(var, "log.date"))
 		return git_config_string(&default_date_mode, var, value);
 	if (!strcmp(var, "log.decorate")) {
+		switch (git_config_maybe_bool(var, value)) {
+		case 0:
+			decoration_style = 0;
+			return 0;
+		case 1:
+			decoration_style = DECORATE_SHORT_REFS;
+			return 0;
+		default:
+			break;
+		}
 		if (!strcmp(value, "full"))
 			decoration_style = DECORATE_FULL_REFS;
 		else if (!strcmp(value, "short"))

Re: [PATCH] Add `log.decorate' configuration variable.

[Steven Drake]

On Tue, 16 Feb 2010, Junio C Hamano wrote:

> This needs some test to make sure that it triggers when configuration is
> set, it doesn't when configuration is not set [...]

Done get wat you mean?

> [...] and it doesn't for commands
> in log family when it shouldn't (most notably, format-patch).

Good point, and looking at the code "log.decorate" only has an affect after
cmd_log_init() is called, which is call by cmd_whatchanged(), cmd_show(), 
cmd_log_reflog() and cmd_log() so only those command are affected
(notably not format-patch).

However if thats not disirable, we could always add
'whatchanged.decorate', 'show.decorate' and reflog.decorate'. 
 
> > +log.decorate::
> > +	Print out the ref names of any commits that are shown by the log
> > +	command. If 'short' is specified, the ref name prefixes 'refs/heads/',
> > +	'refs/tags/' and 'refs/remotes/' will not be printed. If 'full' is
> > +	specified, the full ref name (including prefix) will be printed.
> > +	This is the same as the log commands '--decorate' option.
> 
> This should be the same as --decorate option, so it should be possible to
> set it as a boolean true to mean "short", i.e.
> 
> 	[log]
>         	decorate
> 		decorate = true
> 
> should be treated exactly the same way as
> 
> 	[log]
>         	decorate = short

I thought about that but did not want start adding git_config_XXX()
functions, but you want to add git_config_maybe_bool() then I would agree
with add your patch on top (and you should do so).

While on the subject of git_config I think die_bad_config() should be an
extern (i.e. decleared in cache.h and a static function) so that it could
be used in git_XXX_config functions for handling error.  Something like:

diff --git a/builtin-log.c b/builtin-log.c
index f096eea..a41a7bb 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -264,6 +264,8 @@ static int git_log_config(const char *var, const char *value, void *cb)
 			decoration_style = DECORATE_FULL_REFS;
 		else if (!strcmp(value, "short"))
 			decoration_style = DECORATE_SHORT_REFS;
+		else
+			die_bad_config(var);
 		return 0;
 	}
 	if (!strcmp(var, "log.showroot")) {

-- 
Steven
UNIX is basically a simple operating system,
but you have to be a genius to understand the simplicity  --- dmr

Re: [PATCH] Add `log.decorate' configuration variable.

[Junio C Hamano]

Steven Drake <sdrake@xnet.co.nz> writes:

> Good point, and looking at the code "log.decorate" only has an affect after
> cmd_log_init() is called, which is call by cmd_whatchanged(), cmd_show(), 
> cmd_log_reflog() and cmd_log() so only those command are affected
> (notably not format-patch).

I was not worried about what your change does.  I am worried about
protecting what the code after your change currently does from future
changes done by other people while you are not actively watching the
patches in flight on this list.

> While on the subject of git_config I think die_bad_config() should be an
> extern (i.e. decleared in cache.h and a static function) so that it could
> be used in git_XXX_config functions for handling error.  Something like:
>
> diff --git a/builtin-log.c b/builtin-log.c
> index f096eea..a41a7bb 100644
> --- a/builtin-log.c
> +++ b/builtin-log.c
> @@ -264,6 +264,8 @@ static int git_log_config(const char *var, const char *value, void *cb)
>  			decoration_style = DECORATE_FULL_REFS;
>  		else if (!strcmp(value, "short"))
>  			decoration_style = DECORATE_SHORT_REFS;
> +		else
> +			die_bad_config(var);

We generally avoid doing this, as we may later want to add different
values to "log.decorate", and keep the older git working as if nothing is
specified, rather than barfing, so that people can access the same
repository, perhaps over NFS, from different machines with varying vintage
of git.

Re: [PATCH] Add `log.decorate' configuration variable.

[Steven Drake]

On Tue, 16 Feb 2010, Junio C Hamano wrote:

> I was not worried about what your change does.  I am worried about
> protecting what the code after your change currently does from future
> changes done by other people while you are not actively watching the
> patches in flight on this list.
Ok, I'll send a new patch that should be a lot better shorty.

Have you commited the git_config_maybe_bool() code?

> We generally avoid doing this, as we may later want to add different
> values to "log.decorate", and keep the older git working as if nothing is
> specified, rather than barfing, so that people can access the same
> repository, perhaps over NFS, from different machines with varying vintage
> of git.
Good point.
 
By the way is it alright to send patches that use inbody-headers and/or 
scissors?
-- 
Steven

Re: [PATCH] Add `log.decorate' configuration variable.

[Bert Wesarg]

On Wed, Feb 17, 2010 at 02:08, Junio C Hamano <gitster@pobox.com> wrote:
> diff --git a/config.c b/config.c
> index 6963fbe..6642d30 100644
> --- a/config.c
> +++ b/config.c
> @@ -322,9 +322,8 @@ unsigned long git_config_ulong(const char *name, const char *value)
>        return ret;
>  }
>
> -int git_config_bool_or_int(const char *name, const char *value, int *is_bool)
> +int git_config_maybe_bool(const char *name, const char *value)
>  {
> -       *is_bool = 1;
>        if (!value)
>                return 1;
>        if (!*value)
> @@ -333,7 +332,14 @@ int git_config_bool_or_int(const char *name, const char *value, int *is_bool)
>                return 1;
>        if (!strcasecmp(value, "false") || !strcasecmp(value, "no") || !strcasecmp(value, "off"))
>                return 0;
> -       *is_bool = 0;
> +       return -1;
> +}
> +
> +int git_config_bool_or_int(const char *name, const char *value, int *is_bool)
> +{
> +       int v = git_config_maybe_bool(name, value);
> +       if (0 <= v)
> +               return v;
>        return git_config_int(name, value);
>  }
What happened with the is_bool parameter?

Bert

Re* [PATCH] Add `log.decorate' configuration variable.

[Junio C Hamano]

Bert Wesarg <bert.wesarg@googlemail.com> writes:

>> +int git_config_bool_or_int(const char *name, const char *value, int *is_bool)
>> +{
>> +       int v = git_config_maybe_bool(name, value);
>> +       if (0 <= v)
>> +               return v;
>>        return git_config_int(name, value);
>>  }
> What happened with the is_bool parameter?

Good eyes.  That was why it was "Perhaps something like this" without any
serious commit message ;-).

How about this?

-- >8 --
Subject: git_config_maybe_bool()

Some configuration variables can take boolean values in addition to
enumeration specific to them.  Introduce git_config_maybe_bool() that
returns 0 or 1 if the given value is boolean, or -1 if not, so that
a parser for such a variable can check for boolean first and then
parse other kinds of values as a fallback.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 cache.h  |    1 +
 config.c |   21 +++++++++++++++++----
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/cache.h b/cache.h
index d478eff..dd3be0a 100644
--- a/cache.h
+++ b/cache.h
@@ -924,6 +924,7 @@ extern int git_config_int(const char *, const char *);
 extern unsigned long git_config_ulong(const char *, const char *);
 extern int git_config_bool_or_int(const char *, const char *, int *);
 extern int git_config_bool(const char *, const char *);
+extern int git_config_maybe_bool(const char *, const char *);
 extern int git_config_string(const char **, const char *, const char *);
 extern int git_config_pathname(const char **, const char *, const char *);
 extern int git_config_set(const char *, const char *);
diff --git a/config.c b/config.c
index 6963fbe..64e41be 100644
--- a/config.c
+++ b/config.c
@@ -322,17 +322,30 @@ unsigned long git_config_ulong(const char *name, const char *value)
 	return ret;
 }
 
-int git_config_bool_or_int(const char *name, const char *value, int *is_bool)
+int git_config_maybe_bool(const char *name, const char *value)
 {
-	*is_bool = 1;
 	if (!value)
 		return 1;
 	if (!*value)
 		return 0;
-	if (!strcasecmp(value, "true") || !strcasecmp(value, "yes") || !strcasecmp(value, "on"))
+	if (!strcasecmp(value, "true")
+	    || !strcasecmp(value, "yes")
+	    || !strcasecmp(value, "on"))
 		return 1;
-	if (!strcasecmp(value, "false") || !strcasecmp(value, "no") || !strcasecmp(value, "off"))
+	if (!strcasecmp(value, "false")
+	    || !strcasecmp(value, "no")
+	    || !strcasecmp(value, "off"))
 		return 0;
+	return -1;
+}
+
+int git_config_bool_or_int(const char *name, const char *value, int *is_bool)
+{
+	int v = git_config_maybe_bool(name, value);
+	if (0 <= v) {
+		*is_bool = 1;
+		return v;
+	}
 	*is_bool = 0;
 	return git_config_int(name, value);
 }

Re: [PATCH] Add `log.decorate' configuration variable.

[Junio C Hamano]

Steven Drake <sdrake@xnet.co.nz> writes:

> Have you commited the git_config_maybe_bool() code?

Not yet, but now you mention it, it probably is a good idea to make the
"maybe" part a separate patch, independent from log.decorate.  It should
be useful elsewhere, I guess.

> By the way is it alright to send patches that use inbody-headers and/or 
> scissors?

If used judiciously, i.e. when it makes it easier to follow the
discussion.  It would sometimes make an important patch more likely to get
buried in a deep thread, though.

Re: [PATCH] Add `log.decorate' configuration variable.

[Heiko Voigt]

On Wed, Feb 17, 2010 at 12:39:52PM +1300, Steven Drake wrote:
> This alows the 'git-log --decorate' to be enabled by default so that normal
> log outout contains ant ref names of commits that are shown.

I implemented the same option once but discarded the patch because of
issues with gitk. If it is enabled you can not use gitk anymore thats
why it was not useful to me because I switch between the two tools
regularly.

Maybe you have an idea how to avoid this?

cheers Heiko