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

Re: [PATCH/RFC 0/9] add long forms for format placeholders

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Mar 29, 2011, 06:46 UTC
Message-ID
<4D918032.3010608@drmicha.warpmail.net>
In-Reply-To
<7vei5qvkgw.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 29.03.2011 02:28:
Show 24 quoted lines
> Will Palmer <wmpalmer@gmail.com> writes:
> 
>> I've been kicking around this series for a while now as part of a larger
>> effort of refactoring the pretty formats. A recent discussion on the
>> list has lead me to believe that this smaller subset may be of use
>> sooner, rather than later.
>>
>> This series attempts to add "long forms" for common format placeholders
>> in the "git log" family of commands, making the way for yet more
>> placeholders to be added without needing to worry too much about the
>> increasingly limited set of available one-letter mnemonics. It also
>> moves towards the possibility of eventual unification with the format
>> options in for-each-ref.
> 
> I don't claim that I read 1300+ long [PATCH 5/9] carefully, but I like the
> direction in which this topic is going very much.
> 
> Except that [PATCH 2/9] looked quite out of place---more like "I wanted to
> sneak this feature in" than "this was needed to keep the resulting code
> backward compatible" or anything like that.
> 
> Off the top of my head, I don't think of a reason to say that [PATCH 3/9]
> is going in a wrong direction---is there a reason to make you worried in
> the particular change?

I'm wondering how much of this could and should be shared with for-each-ref. Notable differences that I'm aware of:

- for-each-ref is about (named) refs which can point to any type of
object; rev-list/log is about commit objects
- for-each-ref deals with "few" objects typically, rev-list/log with many

So, other than %(refname), %(upstream) and %(tagger...), all for-each-ref placeholders make sense for rev-list/log.

Sharing the parser would serve several purposes:
- reduced code
- increased test coverage (for-each-ref tests would test the parser)
- speed up for for-each-ref (due to your nice separation)
- short placeholders for for-each-ref
- automatic consistency between the two
Michael
Previous: Will PalmerNext: Will Palmer
Message 13 of 14 in “add long forms for format placeholders”
  1. 0/9 add long forms for format placeholdersWill Palmer, Mar 28, 2011
  2. 1/9 mention --date=raw in rev-list and blame helpWill Palmer, Mar 28, 2011
  3. 2/9 add support for --date=unix to complement %atWill Palmer, Mar 28, 2011
  4. 3/9 interpret %C(invalid) as we would %%C(invalid)Will Palmer, Mar 28, 2011
  5. 4/9 add sanity length check to format_person_partWill Palmer, Mar 28, 2011
  6. 5/9 refactor pretty.c into "parse" and "format" stepsWill Palmer, Mar 28, 2011
  7. 6/9 add long-form %(wrap:...) for %w(...)Will Palmer, Mar 28, 2011
  8. 7/9 add long form %(color:...) for %C(...)Will Palmer, Mar 28, 2011
  9. 8/9 add long forms %(authordate) and %(committerdate)Will Palmer, Mar 28, 2011
  10. 9/9 add long forms for author and committer identityWill Palmer, Mar 28, 2011
  11. Junio C HamanoMar 29, 2011
  12. Will PalmerMar 29, 2011
  13. Michael J GruberMar 29, 2011
  14. Will PalmerMar 29, 2011

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.