This allows for semantically better handling of decoration type.
Signed-off-by: Nazri Ramliy <ayiehere@xxxxxxxxx>
---
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@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html