Skip to content

blame: read diff config #270

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

derrickstolee
Copy link

I had a support email where a user could not make sense of some blame output and the diff they saw when looking at the commit. When I saw the commit, the diff looked like the file was completely rewritten. However, with the "--patience" option, the output looked much cleaner and clearly that line was not modified by that commit.

I could not find a way to modify the diff algorithm used by 'git blame' using config options or command-line arguments, so I thought it would be worth reading the diff config settings in the blame builtin. If we want to start taking command-line options, then that could be handled by a later series.

When users use custom diff settings in their Git config, they
expect all diff algorithms to use those values. In particular,
some diffs change greatly if the "patience" algorithm is used
instead of the default.

In cases where the diff config changes the diff output, the
output of 'git blame' can also change. This alters the user's
expectations, as they look at the diff for that commit and
cannot understand how the line was changed by that commit.

Read the diff config options in 'git blame' so the diff algorithm
uses these options.

Signed-off-by: Derrick Stolee <[email protected]>
@derrickstolee
Copy link
Author

This doesn't work at all.

@dscho
Copy link
Member

dscho commented Jun 18, 2019

This doesn't work at all.

I am curious: why?

Is it because git blame uses a lower-level route into the diff machinery?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants