git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Add support for commit attributes

From
DGDiego Lago González <diego.lago.gonzalez@gmail.com>
Date
Apr 10, 2014, 06:32 UTC
Message-ID
<CAFozjsg_sta+c4=Cbrj=cfS=geOnnWic4wU_hd6=1Gaf4PAUcg@mail.gmail.com>
In-Reply-To
<CACsJy8BJw3+=vSHzfBYigoK6ejt-DNHJPTcOWS3Nv=zxpF1f7g@mail.gmail.com>
2014-04-10 6:25 GMT+02:00 Duy Nguyen <pclouds@gmail.com>:
Show 28 quoted lines
> On Thu, Apr 10, 2014 at 2:38 AM, Diego Lago
> <diego.lago.gonzalez@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
Previous: Duy NguyenNext: Junio C Hamano
Message 3 of 8 in “Add support for commit attributes”
  1. Add support for commit attributesDiego Lago, Apr 9, 2014
  2. Duy NguyenApr 10, 2014
  3. Diego Lago GonzálezApr 10, 2014
  4. Junio C HamanoApr 10, 2014
  5. Junio C HamanoApr 10, 2014
  6. Felipe ContrerasApr 10, 2014
  7. Max HornApr 10, 2014
  8. Duy NguyenApr 10, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.