mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Elijah Newren <>
To: Junio C Hamano <>
Cc: "Matthieu Moy" <>,
	"Eckhard Maaß" <>,
	"Git Mailing List" <>,
	"Jeff King" <>, "Ben Peart" <>
Subject: Re: [PATCH v2] wt-status: use rename settings from init_diff_ui_defaults
Date: Tue, 1 May 2018 17:08:27 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, May 1, 2018 at 4:11 PM, Junio C Hamano <> wrote:
> Elijah Newren <> writes:
>> I'm not certain what the default should be, but I do believe that it
>> should be consistent between these commands.  I lean towards
>> considering break detection being on by default a good thing, but
>> there are some interesting issues to address:
>>   - there is no knob to adjust break detection for status, only for
>> diff/log/show/etc.
>>   - folks have a knob to turn break detection on (for diff/log/show),
>> but not one to turn it off
>>   - for status, break detection makes no sense if rename detection is off.
>>   - for diff/log/show, break detection provides almost no value if
>> rename detection is off (only a dissimilarity index), suggesting that
>> if user turns rename detection off and doesn't explicitly ask for
>> break detection, then it's a waste of time to have it be on
>>   - merge-recursive would break horribly right now if someone turned
>> break detection on for it.  Turning it on might be a good long term
>> goal, but it's not an easy change.
> Many of the issues in the above list are surmountable.  A new option
> could be added to "status" to enable break or "diff" family to
> disable it if we really wanted to.  A new "rewritten" state can be
> added alongside with "modified" to "status" output.
> A more serious issue around "-B" is this one:
> Even though the message is back from 2015 and asks users not to use
> -B/-M together for anything critical "for now", the issue has not
> been resolved and the same bug remains with us in the current code.
> In the longer term, I suspect that it might make sense to have an
> option to let users choose among "I do not want to have anything to
> do with -B", "I always want -B when I ask for -M" and "I always want
> -B whether I ask for -M".  But unfortunately the latter two with the
> current codebase is an unacceptably risky/broken choice.

Very interesting; I didn't know that break detection and rename
detection were unsafe to use together.

I also just realized that in addition to status being inconsistent
with diff/log/show, it was also inconsistent with itself -- it handles
staged and unstaged changes differently.
(wt_status_collect_changes_worktree() had different settings for break
detection than wt_status_collect_changes_index().)

Eckhard, can you add some comments to your commit message mentioning
the email pointed to by Junio about break detection and rename
detection being unsafe to use together, as well as the inconsistencies
in break detection between different commands?  That may help future
readers understand why break detection was turned off for

  reply	other threads:[~2018-05-02  0:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2018-05-01  9:49 ` [PATCH v2] wt-status: use rename settings from init_diff_ui_defaults Eckhard S. Maaß
2018-05-01 11:00   ` Ævar Arnfjörð Bjarmason
2018-05-01 11:37     ` Eckhard Maaß
     [not found] ` <>
2018-05-01 11:09   ` Matthieu Moy
2018-05-01 11:43     ` Eckhard Maaß
2018-05-01 12:23       ` Matthieu Moy
2018-05-01 15:52         ` Elijah Newren
2018-05-01 23:11           ` Junio C Hamano
2018-05-02  0:08             ` Elijah Newren [this message]
2018-05-02 14:20               ` Ben Peart
2018-05-03  5:22               ` Eckhard Maaß
2018-05-04 11:12               ` [PATCH v3] wt-status: use settings from git_diff_ui_config Eckhard S. Maaß
2018-05-04 15:13                 ` Elijah Newren
2018-05-01 16:09         ` [PATCH v2] wt-status: use rename settings from init_diff_ui_defaults Eckhard Maaß

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:

  List information:

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

  git send-email \ \ \ \ \ \ \ \ \

* 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

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).