[PATCH 1/4] commit.h: add 'type' to struct name_decoration

[Nazri Ramliy <ayiehere@gmail.com>]

This allows for semantically better handling of decoration type.

Signed-off-by: Nazri Ramliy <ayiehere@gmail.com>
---
I have splitted the patch into four logical commits:

      1. commit.h: add 'type' to struct name_decoration
      2. log-tree.c: Use struct name_decoration's type for classifying decoration
      3. log --decorate: Colorize commit decorations
      4. Allow customizable coloring of commit decorations

This should make it easier for you (or anyone else)  to spot any problem with
my approach in colorizing --decorate stuff.

This is the first commit, and the rest will follow suit.

My reply to your comments are as follows:

On Fri, Jun 18, 2010 at 4:22 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Configuration variable names are either 2-level or 3-level.  There are
> existing examples for <slot> (e.g. color.branch.<slot>).

Fixed. Now the slots are no longer tied to log, and they are named like
this:

        color.decorate.reflocal
        color.decorate.refremote
        color.decorate.reftag
        color.decorate.refstash
        color.decorate.refhead

This should allow for handling different type of decorations in the
future.

> I don't think any of the above belongs to "decorate.c", which is the
> generic mechanism to annotate commits with arbitrary data.  The Porcelain
> feature "log --decorate" is just one user that happens to use refname as
> that "arbitrary data", and that is what you are coloring.  The code for
> that is in log-tree.c, I think.
>
>> diff --git a/decorate.h b/decorate.h
>> index e732804..d593d32 100644
>
> So is any change to this file.

Fixed. decorate.[ch] is no longer affected by this series.

> When color is not in use (e.g. output is not going to the terminal), you
> would lose "tag: " prefix, wouldn't you?

No. The "tag: " prefix is not lost. It will be shown by show_decorations() if
the type of the decoration matches DECORATION_REF_TAG.

>> +     else if (!prefixcmp(refname, "refs/stash"))
>> +             type = DECORATION_STASH;
>> +     else if (!prefixcmp(refname, "HEAD"))
>> +             type = DECORATION_HEAD;
>
> I suspect that users would expect DECORATION_HEAD to be used to highlight
> the object at the tip of the current branch, but I also suspect this code
> would not do so.

No the code would not do so. It would only colorize the literal printed 'HEAD'
string. The current --decorate shows only 'HEAD' for symbolic refs (is this the
right term for it?) and nothing else (it seems that way to me, I might be wrong
here).

nazri

 commit.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/commit.h b/commit.h
index 6ef88dc..ba818fc 100644
--- a/commit.h
+++ b/commit.h
@@ -28,6 +28,7 @@ extern const char *commit_type;
 extern struct decoration name_decoration;
 struct name_decoration {
 	struct name_decoration *next;
+	int type;
 	char name[1];
 };
 
-- 
1.7.1.245.g7c42e.dirty