From: Elijah Newren <newren@gmail.com>
To: Ramsay Jones <ramsay@ramsayjones.plus.com>
Cc: ben.woosley@gmail.com, Junio C Hamano <gitster@pobox.com>,
GIT Mailing-list <git@vger.kernel.org>
Subject: Re: make test Unexpected passes
Date: Fri, 22 Apr 2016 15:19:51 -0700 [thread overview]
Message-ID: <CABPp-BFdzu4stEfbGAiqDwRAXt7EcvYBEVz1kChJaR4udC5SXA@mail.gmail.com> (raw)
In-Reply-To: <571A8404.5030200@ramsayjones.plus.com>
On Fri, Apr 22, 2016 at 1:05 PM, Ramsay Jones
<ramsay@ramsayjones.plus.com> wrote:
> Hi Ben, Junio,
>
> In the second case, t6036-*.sh, git bisect fingered commit b61f9d6e
> ("ll-merge: use a longer conflict marker for internal merge", 14-04-2016).
Yeah, the t6036 testcase 'git detects conflict w/
criss-cross+contrived resolution' could be made to pass by tweaking
the conflict markers. In fact, any tweak would make it appear to
pass, but the test could be updated to still fail by updating the
contrived resolution of a previous merge to use the newer conflict
marker style as well.
The test is kind of fragile in this way, and is really there just to
document this slightly weird and never seen in practice corner case.
I don't think we'll ever fix the underlying "problem"; not even sure
if it's possible without fundamentally re-thinking our merge strategy
altogether. I just thought that when I was writing all those tests
that documenting this particular behavior as a testcase had some
value, but if the conflict markers are going to be updated
periodically, then the cost of the test may outweigh its value and we
should just toss this one test from that file.
Elijah
next prev parent reply other threads:[~2016-04-22 22:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-22 20:05 make test Unexpected passes Ramsay Jones
2016-04-22 22:19 ` Elijah Newren [this message]
2016-04-27 22:05 ` Junio C Hamano
2016-04-27 22:39 ` Elijah Newren
2016-04-22 23:16 ` Ben Woosley
2016-04-24 19:09 ` Junio C Hamano
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=CABPp-BFdzu4stEfbGAiqDwRAXt7EcvYBEVz1kChJaR4udC5SXA@mail.gmail.com \
--to=newren@gmail.com \
--cc=ben.woosley@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=ramsay@ramsayjones.plus.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 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).