git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Stefan Moch <stefanmoch@mail.de>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Simon Doodkin <helpmepro1@gmail.com>,
	git@vger.kernel.org, Stefan Beller <sbeller@google.com>
Subject: Re: feature-request: git "cp" like there is git mv.
Date: Mon, 19 Mar 2018 13:03:43 -0700	[thread overview]
Message-ID: <xmqq370vvnmo.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20180318210908.3ed94777.stefanmoch@mail.de> (Stefan Moch's message of "Sun, 18 Mar 2018 21:09:08 +0100")

Stefan Moch <stefanmoch@mail.de> writes:

> Are such redundant checks in general a pattern worth searching
> for and cleaning up globally? Or is this rather in the category
> of cleaning up only when noticed?

A clean-up patch that is otherwise a no-op is still welcome as it
will improve the health of the codebase, but they become hindrances
if there are too many of them to consume the review bandwidth that
would otherwise be better spent on other non no-op topics, and/or if
they add too many merge conflicts with other non no-op topics in
flight.

The amount of such negative impact a no-op clean-up patch can have
on the project does not depend on how the issue was discovered, so
we do not even have to know if the issue was discovered by actively
hunting or by noticing while working on a near-by area.

It is possible that by actively looking for, you may end up
producing more of the no-op clean-up patches and can more easily
interfere with other topics, which we may need to discourge or at
least ask you to slow down.  On the other hand, issues discovered
while working on a near-by area would typically not increase
conflicts with other topics in flight over the conflicts that would
be caused by that real work you were doing in a near-by area
already, so in that sense, "only when noticed" is a practical way to
avoid the clean-up fatigue.

  reply	other threads:[~2018-03-19 20:03 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-12 10:53 feature-request: git "cp" like there is git mv Simon Doodkin
2017-12-13 16:39 ` Johannes Schindelin
2017-12-13 17:21   ` Randall S. Becker
2017-12-16  1:31 ` Jonathan Nieder
2017-12-31 19:11   ` Stefan Moch
2017-12-31 19:11     ` [PATCH 1/2] Add test case for mv --dry-run to t7001-mv.sh Stefan Moch
2017-12-31 19:11     ` [PATCH 2/2] mv: remove unneeded 'if (!show_only)' Stefan Moch
2018-02-07 19:49     ` feature-request: git "cp" like there is git mv Junio C Hamano
2018-02-07 20:27       ` Stefan Beller
2018-03-18 20:09       ` Stefan Moch
2018-03-19 20:03         ` Junio C Hamano [this message]
2017-12-18  0:28 ` Igor Djordjevic

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=xmqq370vvnmo.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=helpmepro1@gmail.com \
    --cc=jrnieder@gmail.com \
    --cc=sbeller@google.com \
    --cc=stefanmoch@mail.de \
    /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).