All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johan Herland <johan@herland.net>
To: Sam Elliott <sam@lenary.co.uk>
Cc: git@vger.kernel.org, "Shawn O. Pearce" <spearce@spearce.org>
Subject: Re: New Proposal (simple) for Metadata in Git Commits: git-meta
Date: Thu, 17 Dec 2009 01:26:40 +0100	[thread overview]
Message-ID: <200912170126.40566.johan@herland.net> (raw)
In-Reply-To: <20091216163036.GE18319@spearce.org>

On Wednesday 16 December 2009, Shawn O. Pearce wrote:
> Sam Elliott <sam@lenary.co.uk> wrote:
> > On 15 Dec 2009, at 23:05, Shawn O. Pearce wrote:
> >> If you dropped the --git-meta-- tags above, JGit would happily
> >> recognize the awesome: and Github: tags, but it might need a bit
> >> more work to recognize the nested user: tag.  Also, you'd be able
> >> to use git-meta on the git and Linux kernel repositories to pull
> >> out and work with Signed-off-by, Acked-by, etc.
> >
> > I'm not entirely sure about this approach. The current implementation
> > also works with PGP-signed tags, where the information is not
> > necessarily going to be at the bottom of the message when i use `git-
> > cat-file -p`. I think it shouldn't be too hard to also have git-meta
> > read any YAML-like data just before the signing message.
> 
> Ah, good point.  But as you point out, it should be simple enough
> to detect a PGP signature on the bottom and just clip that off the
> end, and then perform the YAML-like data parsing on the footer.

I agree with Shawn's point that it should be possible to do this without 
embedding it in custom ---tags---.

I would even try to parse the _entire_ commit message, and then discard 
everything that didn't match the "<word>: <free-form value>" format (with 
possible continuation lines). Even though this will generate some false 
positives (probably non-sensical "key: value" pairs), I don't see this as a 
major problem , since most users of this functionality are looking for a 
small set of specific keywords (which are even more unlikely to turn up as 
false positives)

In future versions of Git, you might also want to check for YAML-like data 
in the notes object corresponding to the commit in question (see git-notes 
in v1.6.6 for more details on the new notes feature). This would allow users 
to add/edit such metadata after the commit was made, without having to 
rewrite the commit itself.


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

      reply	other threads:[~2009-12-17  0:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-15 21:27 New Proposal (simple) for Metadata in Git Commits: git-meta Sam Elliott
2009-12-15 22:05 ` Shawn O. Pearce
     [not found]   ` <7349A827-41D5-434F-85FE-D49980A7D501@lenary.co.uk>
2009-12-16 16:30     ` Shawn O. Pearce
2009-12-17  0:26       ` Johan Herland [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200912170126.40566.johan@herland.net \
    --to=johan@herland.net \
    --cc=git@vger.kernel.org \
    --cc=sam@lenary.co.uk \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.