8000 Rename detection using diff.renames by ben · Pull Request #1985 · libgit2/libgit2 · GitHub
[go: up one dir, main page]

Skip to content

Rename detection using diff.renames #1985

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

Merged
merged 7 commits into from
Dec 11, 2013
Merged

Rename detection using diff.renames #1985

merged 7 commits into from
Dec 11, 2013

Conversation

ben
Copy link
Member
@ben ben commented Dec 4, 2013

As noticed in libgit2/libgit2sharp#573 (comment), there's an unsupported use-case with git_diff_find_similar, where the caller wants to obey the diff.renames config value for how hard to try, but possibly override some or all of the threshold values (i.e. git diff -B70%).

  • Add new similarity configuration flag
  • Implement the right behavior
  • Decide whether it should be the default
  • Tests

8000
@@ -468,6 +468,9 @@ typedef int (*git_diff_line_cb)(
* Flags to control the behavior of diff rename/copy detection.
*/
typedef enum {
/** Try to obey `find.renames` */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do, or do not. There is no try.

Also: diff.renames!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😊

@@ -468,6 +468,9 @@ typedef int (*git_diff_line_cb)(
* Flags to control the behavior of diff rename/copy detection.
*/
typedef enum {
/** Obey `diff.renames`. This is overridden by any other GIT_DIFF_FIND_ALL flag. */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@ben
Copy link
Member Author
ben commented Dec 5, 2013

There, now it works. Next question: should GIT_DIFF_FIND_BY_CONFIG be the default? Again reiterating from that other conversation:

  • 👎 Might be confusing if you call git_diff_find_similar and nothing actually happens.
  • 👍 git diff behaves that way.

What do y'all think?

opts->flags = GIT_DIFF_FIND_RENAMES | GIT_DIFF_FIND_COPIES;
else if (val) {
if (!strcasecmp(val, "false"))
return GIT_PASSTHROUGH;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of using an error here, I think it is enough to just return 0 and then after the normalize_find_opts returns, if (opts & GIT_DIFF_FIND_ALL) == 0 then just return 0 because no find options were turned on.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice. I like that better.

@dahlbyk
Copy link
Member
dahlbyk commented Dec 6, 2013

should GIT_DIFF_FIND_BY_CONFIG be the default?

To reiterate my response: this seems like the most reasonable default to me, and the concern about git_diff_find_similar doing nothing seems easily mitigated by a bit of documentation.

* Combination of git_diff_find_t values (default FIND_BY_CONFIG). Note
* that if the configuration value is falsy, this will result in
* `git_diff_find_similar` doing nothing.
*/
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dahlbyk, is this a strong-enough warning?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would slightly prefer a more explicit if-you-do-this-you-may-get-that wording, like "If you don't pass in any explicit find actions and rely on the default behavior from the user configuration, diff.renames could be false which will result in git_diff_find_similar doing nothing"

* Combination of git_diff_find_t values (default FIND_BY_CONFIG).
* Note that if you don't explicitly set this, `diff.renames` could be set
* to false, resulting in `git_diff_find_similar` doing nothing.
*/
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How's this?

Copy link
Member
8000

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💯

@ben
Copy link
Member Author
ben commented Dec 11, 2013

Any more comments? I think this is ready to go.

@arrbee
Copy link
Member
arrbee commented Dec 11, 2013

Yes, I think it's fine. I hesitated to merge it because I know that it's going to conflict with #1986 in a somewhat painful way and was thinking it would probably be easier to rebase this on top of that than resolve these changes there, but since I'm now on a mission to make sure that #1986 has strong test coverage, we should probably just merge this and I'll deal.

arrbee added a commit that referenced this pull request Dec 11, 2013
Rename detection using diff.renames
@arrbee arrbee merged commit 0eedacb into development Dec 11, 2013
@ben ben deleted the diff-rename-config branch December 11, 2013 22:24
phatblat pushed a commit to phatblat/libgit2 that referenced this pull request Sep 13, 2014
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.

3 participants
0