Skip to content

Diff Options has same behaviour for no_locations and track_filename #2020

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

Open
uberroot4 opened this issue May 21, 2025 · 2 comments
Open

Diff Options has same behaviour for no_locations and track_filename #2020

uberroot4 opened this issue May 21, 2025 · 2 comments
Labels
acknowledged an issue is accepted as shortcoming to be fixed feedback requested

Comments

@uberroot4
Copy link

Current behavior 😯

Hi,

I just saw today that the Setters for the Diff-Options in gix/src/diff.rs has the same implementation for the no_locations and track_filename:

gitoxide/gix/src/diff.rs

Lines 67 to 78 in 5f9de52

impl Options {
/// Do not keep track of filepaths at all, which will leave all `location` fields empty.
pub fn no_locations(&mut self) -> &mut Self {
self.location = Some(Location::FileName);
self
}
/// Keep track of file-names, which makes `location` fields usable with the filename of the changed item.
pub fn track_filename(&mut self) -> &mut Self {
self.location = Some(Location::FileName);
self
}

The doc for the no_locations method says Do not keep track of filepaths at all [...], for the track_filename it says Keep track of [...].

Expected behavior 🤔

Based on the documentation of the no_locations method I would expect an impl like this:

/// Do not keep track of filepaths at all, which will leave all `location` fields empty.
pub fn no_locations(&mut self) -> &mut Self {
    self.location = None;
    self
}

Git behavior

/

Steps to reproduce 🕹

No response

@Byron
Copy link
Member

Byron commented May 21, 2025

That's a great catch and definitely looks like an… urm… copy-paste error. I wonder what the purpose of this API was, but it's obviously not tested either as more of a translation layer or API wrap.

A PR would definitely welcome if you'd want to contribute that.

Is that something you are interested in?

@Byron Byron added feedback requested acknowledged an issue is accepted as shortcoming to be fixed labels May 21, 2025
@uberroot4
Copy link
Author

Is that something you are interested in?

Yes would be nice. What would you expect to be included? I'll try to find some time next week

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
acknowledged an issue is accepted as shortcoming to be fixed feedback requested
Projects
None yet
Development

No branches or pull requests

2 participants