Re: [PATCH] Add support for commit attributes
2014-04-10 6:25 GMT+02:00 Duy Nguyen pclo...@gmail.com: On Thu, Apr 10, 2014 at 2:38 AM, Diego Lago diego.lago.gonza...@gmail.com wrote: Commit attributes are custom commit extra headers the user can add to the commit object. The motivation for this patch is that in my company we have a custom continuous integration software that uses a custom formatted commit message (currently in YALM format) to show several information into our CI server front-end. But this YALM-based commit message pollutes the commit object not being human readable, so a good form of achieve the YALM's behaviour (without using YALM nor any other structured language) is to add custom attributes to the commit object itself. For example, in our CI server we show the risk of the change (that can be low, medium or high); we, as said before, add this information by putting YALM code inside the commit message, but the problem is that this message is not human readable. If the problem is polluting human eyes, wouldn't it be better to make git-log to filter it out? For example, we could tell git that all fields (in the message body) that start with X- are rubbish, so instead of showing X-something: base64 stuff..., it shows X-something: filtered out instead? At least people will see that this commit carries human-unreadable stuff. -- Duy Writing this data into the message, the user is forced to write it in the correct format (I think is better to write key=value pairs as an option instead of writing as message lines with spaces in key, between key and equal sign and value, and other mistakes). And is simpler to parse these attributes than the message itself. And, what if the log message is seen from the command line instead of our CI front-end? Why the CLI user (for example) should see information that does not need or does not want to see? Commit attributes are extra information, not the main information, hence this patch. PD: Sorry for the previous message not in plain text. -- Diego Lago González -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add support for commit attributes
On Thu, Apr 10, 2014 at 1:27 PM, Diego Lago González diego.lago.gonza...@gmail.com wrote: Writing this data into the message, the user is forced to write it in the correct format (I think is better to write key=value pairs as an option instead of writing as message lines with spaces in key, between key and equal sign and value, and other mistakes). And is simpler to parse these attributes than the message itself. the interpret-trailers series Christian Couder is cooking in 'pu' should handle this. And, what if the log message is seen from the command line instead of our CI front-end? Why the CLI user (for example) should see information that does not need or does not want to see? which is why git-log (and all other porcelain commands) should learn to hide the value part (but not the key part). -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add support for commit attributes
Duy Nguyen pclo...@gmail.com writes: If the problem is polluting human eyes, wouldn't it be better to make git-log to filter it out? For example, we could tell git that all fields (in the message body) that start with X- are rubbish, so instead of showing X-something: base64 stuff..., it shows X-something: filtered out instead? At least people will see that this commit carries human-unreadable stuff. We had lengthy discussions in early 2010 [*1*]. The whole thread, at least the whole sub-thread that contains the focused message, is a required reading to understand where we stand with respect to extra headers in commit objects. Any additional information about the commit can be added this patch implements is exactly the kind of thing we want to avoid, which made Linus say in an even older discussion [*2*]: No this random field could be used this random way crud, please. Even worse, the --attr pretends to be opaque by not defining what each attribute really means, but the patch hardcodes arbitrary rules like an attribute is unconditionally copied during amends and an attribute cannot be multi-valued, if I read it correctly. I actually think this recording information about commits is exactly the use-case notes were invented to address, and if it is found cumbersome to use, the reason why it is cumbersome needs to be discovered and use of notes needs to be improved. Hooks and/or a wrapper around git commit to implement their custom workflow may be involved as part of the solution and git notes may need to learn a new trick or two along the way. I am not interested in hearing let's add random crud to commit object header before let's improve notes so that it can be more smoothly used is fully explored. [References] *1* http://thread.gmane.org/gmane.comp.version-control.git/138848/focus=138892 *2* http://thread.gmane.org/gmane.comp.version-control.git/19126/focus=19149 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add support for commit attributes
Junio C Hamano gits...@pobox.com writes: I actually think this recording information about commits is exactly the use-case notes were invented to address, and if it is found cumbersome to use, the reason why it is cumbersome needs to be discovered and use of notes needs to be improved. Hooks and/or a wrapper around git commit to implement their custom workflow may be involved as part of the solution and git notes may need to learn a new trick or two along the way. I am not interested in hearing let's add random crud to commit object header before let's improve notes so that it can be more smoothly used is fully explored. Oh, I forgot to say that I do not have anything against embedding the extra info as part of the free-form log message text part of the commit object like you have been suggesting. If the information can be cast in stone at the commit time, that would actually be preferrable, as you do not have to worry about transferring notes separately. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Add support for commit attributes
Diego Lago wrote: Commit attributes are custom commit extra headers the user can add to the commit object. The motivation for this patch is that in my company we have a custom continuous integration software that uses a custom formatted commit message (currently in YALM format) to show several information into our CI server front-end. These attributes can be used for remote-helpers as well; to store extra information that cannot be stored otherwise in Git's data structures. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add support for commit attributes
On 10.04.2014, at 19:28, Felipe Contreras felipe.contre...@gmail.com wrote: Diego Lago wrote: Commit attributes are custom commit extra headers the user can add to the commit object. The motivation for this patch is that in my company we have a custom continuous integration software that uses a custom formatted commit message (currently in YALM format) to show several information into our CI server front-end. These attributes can be used for remote-helpers as well; to store extra information that cannot be stored otherwise in Git's data structures. +1 to that. This is reminds me of what Kiln Harmony does as part of their effort to enable full round-robin transfer between Git and Mercurial (a goal from which all other tools I know of still are far away). See http://blog.fogcreek.com/kiln-harmony-internals-the-basics/. Cheers, Max signature.asc Description: Message signed with OpenPGP using GPGMail
[PATCH] Add support for commit attributes
Commit attributes are custom commit extra headers the user can add to the commit object. The motivation for this patch is that in my company we have a custom continuous integration software that uses a custom formatted commit message (currently in YALM format) to show several information into our CI server front-end. But this YALM-based commit message pollutes the commit object not being human readable, so a good form of achieve the YALM's behaviour (without using YALM nor any other structured language) is to add custom attributes to the commit object itself. For example, in our CI server we show the risk of the change (that can be low, medium or high); we, as said before, add this information by putting YALM code inside the commit message, but the problem is that this message is not human readable. To solve this in Git, we can use this patch to add a commit attribute indicating the risk of the commit out of the commit message, so that commit message can be a normal message (git notes would be a good approach, but this information is not inside of the commit object and in my company we need the commit carries the whole information). We could achieve this behaviour using git notes, but this approach implies using two operations per commit, and we have found with complaints from users. For example, to do a commit with 'risk' attribute, we would do: $ edit file.txt $ git add file.txt $ git commit -m Commit message. --attr risk=low file.txt Attributes are not shown in normal git log/show. They must be obtained in an explicit way. For example, to show the previous attribute, we would do: $ git log -1 --format=%A(risk) low $ git log -1 --format=%A(not_found) %A(not_found) $ git log -1 --format=%A?(not_found) $ Diego Lago (1): Add support for commit attributes Documentation/git-commit.txt | 12 ++- Documentation/pretty-formats.txt | 17 builtin/commit.c | 200 ++ pretty.c | 41 t/t2400-commit-attributes.sh | 187 +++ 5 files changed, 456 insertions(+), 1 deletion(-) create mode 100755 t/t2400-commit-attributes.sh -- 1.7.9.5 From 5d63d32fc94c5824e6189092065160eaf075ff5e Mon Sep 17 00:00:00 2001 From: Diego Lago diego.lago.gonza...@gmail.com Date: Tue, 8 Apr 2014 17:29:48 +0200 Subject: [PATCH] Add support for commit attributes Commit objects support extended attributes using '-A' or '--attr' flag to add them with 'git commit' command. Also, commit attributes are obtained using '%A(...)' format in git log and git show command. Examples: git commit -m Commit message. --attr name=value git log -1 --format=%A(name) # Shows 'value'. In addition, documentation and tests have been added. Signed-off-by: Diego Lago diego.lago.gonza...@gmail.com --- Documentation/git-commit.txt | 12 ++- Documentation/pretty-formats.txt | 17 builtin/commit.c | 200 ++ pretty.c | 41 t/t2400-commit-attributes.sh | 187 +++ 5 files changed, 456 insertions(+), 1 deletion(-) create mode 100755 t/t2400-commit-attributes.sh diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 429267a..7967eca 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -13,7 +13,7 @@ SYNOPSIS [-F file | -m msg] [--reset-author] [--allow-empty] [--allow-empty-message] [--no-verify] [-e] [--author=author] [--date=date] [--cleanup=mode] [--[no-]status] - [-i | -o] [-S[keyid]] [--] [file...] + [(-A | --attr) key=value] [-i | -o] [-S[keyid]] [--] [file...] DESCRIPTION --- @@ -304,6 +304,16 @@ configuration variable documented in linkgit:git-config[1]. commit message template when using an editor to prepare the default commit message. +-A key=value:: +--attr=key=value:: + Add an attribute (extra header) to the commit object. The attribute form + is a 'key=value' pair and neither the key nor the value cannot be empty (if + the commit is an amend commit, value can be empty). You can add as many + attributes as you want and these attributes can be shown either by + linkgit:git-log[1] or linkgit:git-show[1]. If used with --amend option, + duplicated attributes are replaced and if attributes have an empty value, + they are removed from the commit object. + -S[keyid]:: --gpg-sign[=keyid]:: GPG-sign commit. diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt index 1d174fd..23d54b6 100644 --- a/Documentation/pretty-formats.txt +++ b/Documentation/pretty-formats.txt @@ -134,6 +134,8 @@ The placeholders are: - '%b': body - '%B': raw body (unwrapped subject and body) - '%N': commit notes +- '%A[?](...)': commit attribute (specifying attribute name inside brackets
Re: [PATCH] Add support for commit attributes
On Thu, Apr 10, 2014 at 2:38 AM, Diego Lago diego.lago.gonza...@gmail.com wrote: Commit attributes are custom commit extra headers the user can add to the commit object. The motivation for this patch is that in my company we have a custom continuous integration software that uses a custom formatted commit message (currently in YALM format) to show several information into our CI server front-end. But this YALM-based commit message pollutes the commit object not being human readable, so a good form of achieve the YALM's behaviour (without using YALM nor any other structured language) is to add custom attributes to the commit object itself. For example, in our CI server we show the risk of the change (that can be low, medium or high); we, as said before, add this information by putting YALM code inside the commit message, but the problem is that this message is not human readable. If the problem is polluting human eyes, wouldn't it be better to make git-log to filter it out? For example, we could tell git that all fields (in the message body) that start with X- are rubbish, so instead of showing X-something: base64 stuff..., it shows X-something: filtered out instead? At least people will see that this commit carries human-unreadable stuff. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html