[PATCH] for-each-ref: document `creatordate` and `creator` fields

[PATCH] for-each-ref: document `creatordate` and `creator` fields

[Eric Wong]

These were introduced back in 2006 at 3175aa1ec28c but
never documented.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
 And I just found these very useful, today!

 I also noticed creator{name,email} aren't supported, yet.
 Perhaps they're worth implementing for consistency.

 Documentation/git-for-each-ref.txt | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
index c6f073c..06208c4 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -142,6 +142,11 @@ In addition to the above, for commit and tag objects, the header
 field names (`tree`, `parent`, `object`, `type`, and `tag`) can
 be used to specify the value in the header field.
 
+For commit and tag objects, the special `creatordate` and `creator`
+fields will correspond to the appropriate date or name-email-date tuple
+from the `committer` or `tagger` fields depending on the object type.
+These are intended for working on a mix of annotated and lightweight tags.
+
 Fields that have name-email-date tuple as its value (`author`,
 `committer`, and `tagger`) can be suffixed with `name`, `email`,
 and `date` to extract the named component.
@@ -153,8 +158,8 @@ line is 'contents:body', where body is all of the lines after the first
 blank line.  The optional GPG signature is `contents:signature`.  The
 first `N` lines of the message is obtained using `contents:lines=N`.
 
-For sorting purposes, fields with numeric values sort in numeric
-order (`objectsize`, `authordate`, `committerdate`, `taggerdate`).
+For sorting purposes, fields with numeric values sort in numeric order
+(`objectsize`, `authordate`, `committerdate`, `creatordate`, `taggerdate`).
 All other fields are used to sort in their byte-value order.
 
 There is also an option to sort by versions, this can be done by using
-- 
EW

Re: [PATCH] for-each-ref: document `creatordate` and `creator` fields

[Junio C Hamano]

Eric Wong <normalperson@yhbt.net> writes:

> These were introduced back in 2006 at 3175aa1ec28c but
> never documented.

Thanks, and I totally forgot about the feature ;-)

> Signed-off-by: Eric Wong <normalperson@yhbt.net>
> ---
>  And I just found these very useful, today!
>
>  I also noticed creator{name,email} aren't supported, yet.
>  Perhaps they're worth implementing for consistency.
>
>  Documentation/git-for-each-ref.txt | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
> index c6f073c..06208c4 100644
> --- a/Documentation/git-for-each-ref.txt
> +++ b/Documentation/git-for-each-ref.txt
> @@ -142,6 +142,11 @@ In addition to the above, for commit and tag objects, the header
>  field names (`tree`, `parent`, `object`, `type`, and `tag`) can
>  be used to specify the value in the header field.
>  
> +For commit and tag objects, the special `creatordate` and `creator`
> +fields will correspond to the appropriate date or name-email-date tuple
> +from the `committer` or `tagger` fields depending on the object type.
> +These are intended for working on a mix of annotated and lightweight tags.
> +
>  Fields that have name-email-date tuple as its value (`author`,
>  `committer`, and `tagger`) can be suffixed with `name`, `email`,
>  and `date` to extract the named component.
> @@ -153,8 +158,8 @@ line is 'contents:body', where body is all of the lines after the first
>  blank line.  The optional GPG signature is `contents:signature`.  The
>  first `N` lines of the message is obtained using `contents:lines=N`.
>  
> -For sorting purposes, fields with numeric values sort in numeric
> -order (`objectsize`, `authordate`, `committerdate`, `taggerdate`).
> +For sorting purposes, fields with numeric values sort in numeric order
> +(`objectsize`, `authordate`, `committerdate`, `creatordate`, `taggerdate`).
>  All other fields are used to sort in their byte-value order.
>  
>  There is also an option to sort by versions, this can be done by using