Re: [PATCH] Add support for commit attributes

[Duy Nguyen]

On Thu, Apr 10, 2014 at 2:38 AM, 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.
>
> 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: " 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

Re: [PATCH] Add support for commit attributes

[Diego Lago González]

2014-04-10 6:25 GMT+02:00 Duy Nguyen :
> On Thu, Apr 10, 2014 at 2:38 AM, 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.
>>
>> 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: " 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

[Duy Nguyen]

On Thu, Apr 10, 2014 at 1:27 PM, Diego Lago González
 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

[Junio C Hamano]

Duy Nguyen  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: " 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]

Junio C Hamano  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

[Felipe Contreras]

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

[Max Horn]

On 10.04.2014, at 19:28, Felipe Contreras  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 
.



Cheers,
Max


signature.asc
Description: Message signed with OpenPGP using GPGMail