From: Junio C Hamano <gitster@pobox•com>
To: Ray Donnelly <mingw.android@gmail•com>
Cc: git@vger•kernel.org, Johannes Schindelin <johannes.schindelin@gmx•de>
Subject: Re: [PATCH 1/2] test-path-utils.c: remove incorrect assumption
Date: Sun, 04 Oct 2015 10:21:08 -0700 [thread overview]
Message-ID: <xmqqwpv21rej.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CAOYw7dv4iPQ4cq4Ab1ZeThrp=u51T5v387a1Y8QPO-yj=fyMcg@mail.gmail.com> (Ray Donnelly's message of "Sun, 4 Oct 2015 15:51:22 +0100")
Ray Donnelly <mingw.android@gmail•com> writes:
>> Some callers of this function in real code (i.e. not the one you are
>> removing the check) do seem to depend on that condition, e.g. the
>> codepath in clone that leads to add_to_alternates_file() wants to
>> make sure it does not add an duplicate, so it may end up not noticing
>> /foo/bar and /foo/bar/ are the same thing, no? There may be others.
>
> Enforcing that normalize_path_copy() removes any trailing '/' (apart
> from the root directory) breaks other things that assume it doesn't
> mess with trailing '/'s, for example filtering in ls-tree. Any
> suggestions for what to do about this? Would a flag be appropriate as
> to whether to do this part or not? Though I'll admit I don't like the
> idea of adding flags to modify the behavior of something that's meant
> to "normalize" something. Alternatively, I could go through all the
> breakages and try to fix them up?
I agree with you that "normalize" should "normalize". Making sure
that all the callers expect the same kind of normalization would be
a lot of work but I do think that is the best approach in the long
run. Thanks for the ls-tree example, by the way, did you find it by
code inspection? I do not think it is reasonable to expect the test
coverage for this to be 100%, so the "try to fix them up" would have
to involve a lot of manual work both in fixing and reviewing,
unfortunately.
The first step of the "best approach" would be to make a note on
normalize_path_copy() by adding a NEEDSWORK: comment to describe the
situation.
Thanks.
next prev parent reply other threads:[~2015-10-04 17:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-03 12:44 [PATCH 1/2] test-path-utils.c: remove incorrect assumption Ray Donnelly
2015-10-03 15:38 ` Ray Donnelly
2015-10-03 17:13 ` Junio C Hamano
2015-10-04 14:51 ` Ray Donnelly
2015-10-04 17:21 ` Junio C Hamano [this message]
2015-10-04 23:36 ` Ray Donnelly
2015-10-08 20:42 ` Ray Donnelly
2015-10-09 1:05 ` Junio C Hamano
2015-10-09 10:12 ` Ray Donnelly
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=xmqqwpv21rej.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=johannes.schindelin@gmx$(echo .)de \
--cc=mingw.android@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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