On Tue, May 1, 2018 at 5:23 AM, Matthieu Moy <git@xxxxxxxxxxxxxxx> wrote:
> "Eckhard Maaß" <eckhard.s.maass@xxxxxxxxxxxxxx>:
>
>> 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
this:
$ 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
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.
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
