From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Elijah Newren <newren@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 2/2] merge-recursive: fix merging a subdirectory into the root directory
Date: Thu, 31 Oct 2019 09:28:52 +0100 (CET) [thread overview]
Message-ID: <nycvar.QRO.7.76.6.1910310927540.46@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <CABPp-BG1ir2kXkxMmNQ2btDKvpSWg9QwcUnoy_5teuNO=JhAFA@mail.gmail.com>
Hi Elijah,
On Wed, 30 Oct 2019, Elijah Newren wrote:
> On Wed, Oct 30, 2019 at 3:17 PM Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Wed, 30 Oct 2019, Elijah Newren wrote:
> >
> > > On Mon, Oct 28, 2019 at 6:20 PM Junio C Hamano <gitster@pobox.com> wrote:
> > > >
> > > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > > >
> > > > >> Still, I rely pretty heavily on t6036, t6042, t6043, and t6046 for
> > > > >> sanity in the face of refactoring and rewriting -- and as mentioned
> > > > >> before they have caught refactoring bugs in those areas that appear at
> > > > >> first blush as "overzealous", ...
> > > > >
> > > > > One idea would be to try to guard those extra careful tests behind the
> > > > > `EXPENSIVE` prereq.
> > > >
> > > > Yeah, I like that---I think it is perfectly in line with the spirit
> > > > of EXPENSIVE, too.
> > >
> > > Or perhaps EXPENSIVE_ON_WINDOWS, since it's actually pretty cheap on
> > > linux and not that bad on Mac
> >
> > Why the complexity? If you separate out the expensive tests (even if
> > they are only expensive in terms of run time on Windows), it will make
> > the regression tests so much more readable to the occasional reader
> > (making them less expensive in terms of reading time...).
>
> The "extra careful" things you were complaining about with the new
> test I was adding to t6043 was true of every single test in that
> file...and likely much of t6036, t6042, and perhaps even t6046 (though
> those have fewer tests than t6043). I have no clue where I'd even
> begin to draw the line between them. If it's possible, it sounds
> extremely complex. Just using the EXPENSIVE_ON_WINDOWS prereq that
> already exists would be easy and simple.
>
> Or did you mean you wanted me to duplicate every single test and
> attempt to trim down the duplicates somehow? That'd be a rather large
> undertaking that sounds rather unappealing on a few fronts, but maybe
> that's what you had in mind?
My suggestion was in reply to your question, and not intended for
already-existing tests. That would indeed require a lot of work, and I
am not sure that it would be worth it.
The suggestion was intended for future patches.
Ciao,
Dscho
next prev parent reply other threads:[~2019-10-31 8:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-11 20:42 [PATCH 0/2] Dir rename fixes Elijah Newren via GitGitGadget
2019-10-11 20:42 ` [PATCH 1/2] merge-recursive: clean up get_renamed_dir_portion() Elijah Newren via GitGitGadget
2019-10-12 19:47 ` Johannes Schindelin
2019-10-11 20:42 ` [PATCH 2/2] merge-recursive: fix merging a subdirectory into the root directory Elijah Newren via GitGitGadget
2019-10-12 20:37 ` Johannes Schindelin
2019-10-13 0:40 ` Elijah Newren
2019-10-14 10:41 ` Johannes Schindelin
2019-10-22 19:15 ` Elijah Newren
2019-10-24 22:22 ` Johannes Schindelin
2019-10-25 0:12 ` Elijah Newren
2019-10-25 13:30 ` Johannes Schindelin
2019-10-29 1:20 ` Junio C Hamano
2019-10-30 7:01 ` Elijah Newren
2019-10-30 22:16 ` Johannes Schindelin
2019-10-30 22:31 ` Elijah Newren
2019-10-31 8:28 ` Johannes Schindelin [this message]
2019-10-12 18:41 ` [PATCH 0/2] Dir rename fixes Johannes Schindelin
2019-10-22 21:22 ` [PATCH v2 0/3] " Elijah Newren via GitGitGadget
2019-10-22 21:22 ` [PATCH v2 1/3] merge-recursive: clean up get_renamed_dir_portion() Elijah Newren via GitGitGadget
2019-10-22 21:22 ` [PATCH v2 2/3] merge-recursive: fix merging a subdirectory into the root directory Elijah Newren via GitGitGadget
2019-10-22 21:22 ` [PATCH v2 3/3] t604[236]: do not run setup in separate tests Elijah Newren via GitGitGadget
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=nycvar.QRO.7.76.6.1910310927540.46@tvgsbejvaqbjf.bet \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=newren@gmail.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).