From: Junio C Hamano <gitster@pobox.com>
To: "Stefan Beller" <sbeller@google.com>, "René Scharfe" <l.s.r@web.de>
Cc: git@vger.kernel.org, jrnieder@gmail.com, peff@peff.net
Subject: Re: [PATCH 1/2] xdiff-interface: export comparing and hashing strings
Date: Fri, 27 Oct 2017 16:12:11 +0900 [thread overview]
Message-ID: <xmqqefppcbec.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <3f656948-273f-e01d-ad52-e460059571da@web.de> ("René Scharfe"'s message of "Thu, 26 Oct 2017 19:12:15 +0200")
René Scharfe <l.s.r@web.de> writes:
> Am 25.10.2017 um 20:49 schrieb Stefan Beller:
>> +/*
>> + * Compare the strings l1 with l2 which are of size s1 and s2 respectively.
>> + * Returns 1 if the strings are deemed equal, 0 otherwise.
>> + * The `flags` given as XDF_WHITESPACE_FLAGS determine how white spaces
>> + * are treated for the comparision.
>> + */
>> +extern int xdiff_compare_lines(const char *l1, long s1,
>> + const char *l2, long s2, long flags);
>
> With the added comment it's OK here.
>
> Still, I find the tendency in libxdiff to use the shortest possible
> variable names to be hard on the eyes. That math-like notation may have
> its place in that external library, but I think we should be careful
> lest it spreads.
Yeah, I tend to agree. The xdiff-interface is at the (surprise!)
interface layer, so we could make it follow the style of either one,
but we seem to have picked up the convention of the lower layer,
so...
By the way, I was looking at the code around this area while
reviewing the cr-at-eol thing, and noticed a couple of things:
* combine-diff.c special cases only IGNORE_WHITESPACE and
IGNORE_WHITESPACE_CHANGE but no other IGNORE_WHITESPACE things; I
have a suspicion that this is not because IGNORE_WHITESPACE_AT_EOL
does not have to special cased by the codepath, but only because
the combine-diff.c refactoring predates the introduction of
ws-at-eol thing?
The machinery uses its own match_string_spaces() helper; it may
make sense to use the same xdiff_compare_lines() in its callers
and get rid of this helper function.
* diff_setup_done() sets DIFF_FROM_CONTENTS when any of the
IGNORE_WHITESPACE bits is true, to allow "git diff -q
--ignore-something" would do the right thing. We do not however
give a similar special case to XDF_IGNORE_BLANK_LINES.
$ echo >>Makefile && git diff $option --ignore-blank-lines Makefile
exits with 1 when option=--exit-code and it exits with 0 when
option=-q
For now I'll leve these as #leftoverbits, but I may come back to the
latter soonish. I won't come back to the former until Stefan's
refactor hits 'master', though.
next prev parent reply other threads:[~2017-10-27 7:12 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-24 18:59 [PATCH 0/4] (x)diff cleanup: remove duplicate code Stefan Beller
2017-10-24 18:59 ` [PATCH 1/4] hashmap: introduce memhash_feed to access the internals of FNV-1 hash Stefan Beller
2017-10-24 20:23 ` René Scharfe
2017-10-24 20:48 ` Stefan Beller
2017-10-24 18:59 ` [PATCH 2/4] xdiff-interface: export comparing and hashing strings Stefan Beller
2017-10-24 20:23 ` René Scharfe
2017-10-24 20:42 ` Stefan Beller
2017-10-26 17:03 ` René Scharfe
2017-10-24 18:59 ` [PATCH 3/4] xdiff: use stronger hash function internally Stefan Beller
2017-10-24 20:23 ` René Scharfe
2017-10-24 20:46 ` Stefan Beller
2017-10-24 23:04 ` Jonathan Nieder
2017-10-24 18:59 ` [PATCH 4/4] diff.c: get rid of duplicate implementation Stefan Beller
2017-10-24 19:02 ` [PATCH 0/4] (x)diff cleanup: remove duplicate code Stefan Beller
2017-10-24 23:42 ` [PATCHv2 0/2] " Stefan Beller
2017-10-24 23:42 ` [PATCH 1/2] xdiff-interface: export comparing and hashing strings Stefan Beller
2017-10-25 4:26 ` Eric Sunshine
2017-10-24 23:42 ` [PATCH 2/2] diff.c: get rid of duplicate implementation Stefan Beller
2017-10-25 5:11 ` [PATCHv2 0/2] (x)diff cleanup: remove duplicate code Junio C Hamano
2017-10-25 18:47 ` Stefan Beller
2017-10-25 18:49 ` [PATCHv3 " Stefan Beller
2017-10-25 18:49 ` [PATCH 1/2] xdiff-interface: export comparing and hashing strings Stefan Beller
2017-10-26 17:12 ` René Scharfe
2017-10-27 7:12 ` Junio C Hamano [this message]
2017-10-27 17:15 ` Stefan Beller
2017-10-25 18:49 ` [PATCH 2/2] diff.c: get rid of duplicate implementation Stefan Beller
2017-10-26 2:23 ` Junio C Hamano
2017-10-26 17:43 ` René Scharfe
2017-10-30 17:59 ` Jeff King
2017-10-30 19:07 ` Jeff King
2017-10-24 23:45 ` [PATCH 1/5] fnv: migrate code from hashmap to fnv Stefan Beller
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=xmqqefppcbec.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=l.s.r@web.de \
--cc=peff@peff.net \
--cc=sbeller@google.com \
/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.