mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Elijah Newren <>
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: Wed, 02 May 2018 08:11:45 +0900	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Elijah Newren's message of "Tue, 1 May 2018 08:52:30 -0700")

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.

> So, where does that leave us?  My opinion is
>   - these commands should be consistent.  Eckhard's patch makes them so.
>   - we might want to move towards break detection being on as the
> default.  That's a couple patch series (one for everything but
> merge-recursive, and a separate much bigger series for
> merge-recursive).
> But I can see others saying we should leave things inconsistent until
> we can fix the other commands to use break detection as the default.
> So...thoughts?
> Elijah

  reply	other threads:[~2018-05-01 23:11 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 [this message]
2018-05-02  0:08             ` Elijah Newren
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).