All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre Habouzit <madcoder@debian.org>
To: git@vger.kernel.org
Cc: torvalds@linux-foundation.org, gitster@pobox.com, peff@peff.net
Subject: Migration of builtin-blame to parse-option
Date: Tue,  8 Jul 2008 11:55:58 +0200	[thread overview]
Message-ID: <1215510964-16664-1-git-send-email-madcoder@debian.org> (raw)

This series is twofold. The first 4 patches refactor the revision
parsing machine so that it's easier to deal with from a parse-opt based
parser:

[PATCH 1/6] revisions: refactor init_revisions and setup_revisions.
21 files changed, 70 insertions(+), 54 deletions(-)

  This is the patch I sent before, revisited.

[PATCH 2/6] revisions: split the pure option parsing out from parse_revisions.
2 files changed, 273 insertions(+), 308 deletions(-)

  This patch splits out the revisions _option_ parsing (as opposed to
  revisions arguments or pseudo arguments like --all, --not, ...) from
  the revision parser. The patch is huge, but quite straightforward.

[PATCH 3/6] revisions: parse_revisions refactor.
1 files changed, 38 insertions(+), 25 deletions(-)

  This patch reworks parse_revisions so that it works internally as if
  it was a parse-opt parser. It's equivalent to the previous code, but
  changes are tricky, and a separate commit is really worth it.

[PATCH 4/6] revisions: split handle_revision_args from parse_revisions.
2 files changed, 52 insertions(+), 46 deletions(-)

  This patch splits out the last bit of parse-revisions (from the
  previous commit) so that what parses revisions arguments (refs and
  pseudo arguments like --all/--not/...) can be called independently.

  The commit is straightforward but moves code around, hence the
  separate commit from patch 3 so that one isn't lost in the code moves
  while reviewing the tricky bits from patch 3.


The second part is the git-blame migration for real:

[PATCH 5/6] git-blame: migrate to incremental parse-option [1/2]
1 files changed, 118 insertions(+), 102 deletions(-)

  This bit is really alike the proof of concept I saw. Most of the code
  is stolen from Linus initial patch. It merely removes the git-blame
  own options and deal with them with a parse-opt parser, in an
  incremental way.

  All in all, it's a pretty straighforward patch.

[PATCH 6/6] git-blame: migrate to incremental parse-option [2/2]
1 files changed, 40 insertions(+), 92 deletions(-)

  This is by far the trickiest patch of the series, though it passes the
  testsuite fine. This patch uses the function from patch 4 to process
  the revision arguments. We know the dashdash position from the
  incremental parse-opt, but we have to deal with the "old way" of
  passing arguments to git-blame.

  The new code is really less involved than before, because we deal with
  a filtered argv array where we only have the revisions arguments (no
  options anymore) and the <path>.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

             reply	other threads:[~2008-07-08  9:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-08  9:55 Pierre Habouzit [this message]
2008-07-08  9:55 ` [PATCH 1/6] revisions: refactor init_revisions and setup_revisions Pierre Habouzit
2008-07-08  9:56   ` [PATCH 2/6] revisions: split the pure option parsing out from parse_revisions Pierre Habouzit
2008-07-08  9:56     ` [PATCH 3/6] revisions: parse_revisions refactor Pierre Habouzit
2008-07-08  9:56       ` [PATCH 4/6] revisions: split handle_revision_args from parse_revisions Pierre Habouzit
2008-07-08  9:56         ` [PATCH 5/6] git-blame: migrate to incremental parse-option [1/2] Pierre Habouzit
2008-07-08  9:56           ` [PATCH 6/6] git-blame: migrate to incremental parse-option [2/2] Pierre Habouzit
2008-07-08 10:51     ` [PATCH 2/6] revisions: split the pure option parsing out from parse_revisions Johannes Sixt
2008-07-08 11:00       ` Pierre Habouzit
2008-07-08 11:25         ` Pierre Habouzit
2008-07-08 10:59   ` [PATCH 1/6] revisions: refactor init_revisions and setup_revisions Johannes Schindelin
2008-07-08 11:06     ` Pierre Habouzit
2008-07-08 11:43       ` Johannes Schindelin
2008-07-08 12:48         ` Pierre Habouzit
2008-07-08 10:02 ` Migration of builtin-blame to parse-option Pierre Habouzit

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=1215510964-16664-1-git-send-email-madcoder@debian.org \
    --to=madcoder@debian.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=torvalds@linux-foundation.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.