Duy Nguyen <pclouds@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html