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

On Tue, May 1, 2018 at 5:23 AM, Matthieu Moy <> wrote:
> "Eckhard Maaß" <>:
>> On Tue, May 01, 2018 at 01:09:06PM +0200, Matthieu Moy wrote:
>> > That init_diff_ui_defaults() should indeed have been before
>> > git_config() from the beginning. My bad, I'm the one who
>> > misplaced it apparently :-(.
>> Should I have done this "bug fix" in a separate commit or mention it in
>> the commit message?
> I'm fine with it as-is. Before your "fix", the config was ignored
> because overwritten by init_diff_ui_defaults() after reading the
> config, so effect of your change is indeed what the commit message
> describes.
> I'm often thinking aloud while reviewing, don't take my comments as
> objections.
>> > This "break_opt = 0" deserves a mention in the commit message IMHO.
>> > I'm not 100% sure it's a good change actually.
>> Hm, what problems do you see here?
> I don't see any "problem", I *think* your change is good, but I can't
> fully convince myself that it is without further explanation.
> Unlike the other two, this option has no corresponding configuration
> variable, so the "let the config" argument doesn't apply. For "git
> status", there's actually not even a command-line option. So, this
> assignment removed, there's no way in the user-interface to re-enable
> the previous behavior. *If* there was a good reason to get "break_opt
> = 0", then your patch is breaking it.
> Unfortunately, the commit introducing it doesn't help much: f714fb8
> (Enable rewrite as well as rename detection in git-status,
> 2007-12-02) is just a one-liner message with a one-liner patch.
> But actually, I never used -B/--break-rewrites, and writting this
> message I tried to get a case where -B would make a difference and I'm
> not even able to find one. So, as someone who never understood the
> real point of -B, I'm not sure I'm qualified to juge on what's the
> best default ;-).

In git.git, just make non-sensical changes like the following (a
normal rename, and a break-rename, for comparison):

    git mv oidset.c another-file.c
    echo "// Modifying normally renamed file for fun" >>another-file.c
    git rm merge.c
    git mv object.c merge.c
    echo "// Random change to break-rename file" >>merge.c
    git add merge.c another-file.c

Now compare, git before Eckhard's change:

$ /usr/bin/git status
HEAD detached at v2.17.0
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    oidset.c -> another-file.c
    renamed:    object.c -> merge.c

and git after Eckhard's change:

$ git status
HEAD detached at v2.17.0
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    oidset.c -> another-file.c
    modified:   merge.c
    deleted:    object.c

Which is better?  Well, gut reaction only looking at the above output
folks would probably say the former is. However, compare the output to

$ git diff --name-status HEAD
R094    oidset.c        another-file.c
M       merge.c
D       object.c

git status and git diff are inconsistent for no good reason.  We can
instruct diff to behave the same as old status, of course:

$ git diff --name-status -B HEAD
R094    oidset.c        another-file.c
R099    object.c        merge.c

...but why does the user have to instruct diff to get the same default
behavior they get from status?  I'll note here that log and show have
the same default as diff.

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

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

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.


  reply	other threads:[~2018-05-01 15:52 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 [this message]
2018-05-01 23:11           ` Junio C Hamano
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).