git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>,
	git@vger.kernel.org, Alex Henrie <alexhenrie24@gmail.com>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v2] builtin/log: honor log.decorate
Date: Fri, 12 May 2017 16:48:14 -0700	[thread overview]
Message-ID: <20170512234814.GG27400@aiede.svl.corp.google.com> (raw)
In-Reply-To: <20170512233753.rz2g7quews4ny5iq@genre.crustytoothpaste.net>

Hi,

brian m. carlson wrote:

> Does anyone else have views on whether this is good thing to test for?

I know you don't mean to be rude, but this comes across as a bit of
a dismissive question.

> On Fri, May 12, 2017 at 04:32:14PM -0700, Jonathan Nieder wrote:
>> brian m. carlson wrote:

>>> The recent change that introduced autodecorating of refs accidentally
>>> broke the ability of users to set log.decorate = false to override it.
>>
>> Yikes.  It sounds to me like we need a test to ensure we don't regress
>> it again later.
>
> I can add one, but it's going to be a bit odd.  The issue is that as far
> as I can tell, the option is honored only if it's the last one read, so
> it necessarily has to be in the per-repository configuration.
>
> I'm not sure it makes that much sense to add a test for this case.  Do
> we generally want to write such tests for all config options?  I don't
> suppose it's that common a mistake to make.

In my humble opinion, the bug being subtle makes it especially useful
to have a test that describes that bug.  That way, if someone is
refactoring this code later then they know what to watch out for not
reintroducing.

I'm happy to hear other opinions, especially if they come with data or
a principle attached that I can use when writing future patches of my
own.

Thanks,
Jonathan

  reply	other threads:[~2017-05-12 23:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-12 21:34 [PATCH] builtin/log: honor log.decorate brian m. carlson
2017-05-12 22:03 ` Alex Henrie
2017-05-12 22:07   ` brian m. carlson
2017-05-12 22:12     ` [PATCH v2] " brian m. carlson
2017-05-12 22:22       ` Alex Henrie
2017-05-12 23:32       ` Jonathan Nieder
2017-05-12 23:37         ` brian m. carlson
2017-05-12 23:48           ` Jonathan Nieder [this message]
2017-05-13  1:23             ` Alex Henrie
2017-05-13  2:49               ` brian m. carlson
2017-05-13  2:41             ` brian m. carlson
2017-05-14 18:00       ` [PATCH v3] " brian m. carlson
2017-05-15  2:35         ` Junio C Hamano
2017-05-15  3:48           ` Alex Henrie
2017-05-15 16:26           ` Jonathan Nieder

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170512234814.GG27400@aiede.svl.corp.google.com \
    --to=jrnieder@gmail.com \
    --cc=alexhenrie24@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sandals@crustytoothpaste.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).