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