git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bo Yang <struggleyb.nku@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Jens.Lehmann@web.de, trast@student.ethz.ch,
	jrnieder@gmail.com
Subject: Re: [PATCH 03/12] add the basic data structure for line level history
Date: Wed, 30 Jun 2010 22:42:30 +0800	[thread overview]
Message-ID: <AANLkTikeqoZeUcnR157VEUVKEYlr0RkYbH_BTb7MMEuj@mail.gmail.com> (raw)
In-Reply-To: <7v39w8gwrw.fsf@alter.siamese.dyndns.org>

On Mon, Jun 28, 2010 at 2:23 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> +/*
>> + * copied from blame.c, indeed, we can even to use this to test
>
> A bit of refactoring would certainly help, before this series graduates
> the WIP/RFC stage.

I have put the 'parse_loc' into the line.c and make blame.c use it.
Please see the commit log. :-)

>> diff --git a/revision.c b/revision.c
>> index 7847921..3186e0e 100644
>> --- a/revision.c
>> +++ b/revision.c
>> @@ -1397,18 +1397,19 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
>>       return 1;
>>  }
>>
>> -void parse_revision_opt(struct rev_info *revs, struct parse_opt_ctx_t *ctx,
>> +int parse_revision_opt(struct rev_info *revs, struct parse_opt_ctx_t *ctx,
>>                       const struct option *options,
>>                       const char * const usagestr[])
>>  {
>>       int n = handle_revision_opt(revs, ctx->argc, ctx->argv,
>>                                   &ctx->cpidx, ctx->out);
>>       if (n <= 0) {
>> -             error("unknown option `%s'", ctx->argv[0]);
>> -             usage_with_options(usagestr, options);
>> +             return -1;
>>       }
>>       ctx->argv += n;
>>       ctx->argc -= n;
>> +
>> +     return 0;
>>  }
>
> The function has existing callers and they expect it to fail with
> usage_with_options(), never to return.  Doesn't this change break them?
>
> This change is not described nor justified in the commit log message.

Yes, this will affect other callers badly. But, with the new one pass
parsing method, we don't need this change anymore, so please forget
it.

>>  static int for_each_bad_bisect_ref(each_ref_fn fn, void *cb_data)
>> @@ -1631,6 +1632,12 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s
>>       if (revs->combine_merges)
>>               revs->ignore_merges = 0;
>>       revs->diffopt.abbrev = revs->abbrev;
>> +
>> +     if (revs->line) {
>> +             revs->limited = 1;
>> +             revs->topo_order = 1;
>> +     }
>> +
>>       if (diff_setup_done(&revs->diffopt) < 0)
>>               die("diff_setup_done failed");
>>
>> diff --git a/revision.h b/revision.h
>> index 855464f..26c2ff5 100644
>> --- a/revision.h
>> +++ b/revision.h
>> @@ -14,6 +14,7 @@
>>  #define CHILD_SHOWN  (1u<<6)
>>  #define ADDED                (1u<<7) /* Parents already parsed and added? */
>>  #define SYMMETRIC_LEFT       (1u<<8)
>> +#define RANGE_UPDATE (1u<<9) /* for line level traverse */
>>  #define ALL_REV_FLAGS        ((1u<<9)-1)
>
> It doesn't make sense to add a global flag here and keep ALL_REV_FLAGS the
> same value.  Have you audited the existing code and made sure that they
> either do use 1<<9 for their own or their uses of such a custom flag are
> compatible with this?
>

Hmm, I really mean the ALL_REV_FLAGS would be ((1u<<10)-1). :-)

And all the other comments from you are very helpful and I have
changed the according it. Thanks a lot!

-- 
Regards!
Bo
----------------------------
My blog: http://blog.morebits.org
Why Git: http://www.whygitisbetterthanx.com/

  reply	other threads:[~2010-06-30 14:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-26 13:27 [PATCH 00/12] The first version of line level log browser Bo Yang
2010-06-26 13:27 ` [PATCH 01/12] parse-options: stop when encounter a non-option Bo Yang
2010-06-26 13:27 ` [PATCH 02/12] parse-options: add two helper functions Bo Yang
2010-06-27 18:22   ` Junio C Hamano
2010-06-30 14:35     ` Bo Yang
2010-06-26 13:27 ` [PATCH 03/12] add the basic data structure for line level history Bo Yang
2010-06-27 18:23   ` Junio C Hamano
2010-06-30 14:42     ` Bo Yang [this message]
2010-06-26 13:27 ` [PATCH 04/12] parse the -L options Bo Yang
2010-06-26 13:27 ` [PATCH 05/12] export three functions from diff.c Bo Yang
2010-06-26 13:27 ` [PATCH 06/12] add range clone functions Bo Yang
2010-06-27 19:54   ` Junio C Hamano
2010-06-26 13:27 ` [PATCH 07/12] map/take range to parent Bo Yang
2010-06-26 13:27 ` [PATCH 08/12] print the line log Bo Yang
2010-06-27 23:49   ` Ramkumar Ramachandra
2010-06-26 13:27 ` [PATCH 09/12] map/print ranges along traversing the history topologically Bo Yang
2010-06-26 13:27 ` [PATCH 10/12] add --always-print option Bo Yang
2010-06-26 13:27 ` [PATCH 11/12] add two test cases Bo Yang
2010-06-26 13:27 ` [PATCH 12/12] some document update Bo Yang

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=AANLkTikeqoZeUcnR157VEUVKEYlr0RkYbH_BTb7MMEuj@mail.gmail.com \
    --to=struggleyb.nku@gmail.com \
    --cc=Jens.Lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=trast@student.ethz.ch \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).