Skip to content
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

Show diff or file content in fzf_search_git_status #124

Closed
wants to merge 1 commit into from

Conversation

ovv
Copy link
Contributor

@ovv ovv commented Feb 14, 2021

No description provided.

# Other files, show the diff compared to last commit (unstaged & staged changes)
case '*'
git diff --color HEAD $argv[2]
end
Copy link
Owner

Choose a reason for hiding this comment

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

My main concern now is this doesn't cover all the cases. Can you help me understand how this correctly covers all the cases?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not 100% sure it covers all the cases. It covers the one I found.

The switch match on a regex-like syntax:

  • case '\?\?': match the untracked files. Those can't be diff by git diff because there are new files so there isn't any previous case to compare them to. Fallback on displaying the whole file.
  • case '?D' 'D?': match files that are deleted, either staged or in the working tree. git diff doesn't support those so we also fall-back on displaying the whole file as it is in the last commit (bat won't work because the file is no longer there).
  • case '*': match any other file status. We display the diff compared with the last commit. This effectively combine the change in the staging area and the working tree in the preview.

There might be other statuses that a git diff can't properly display, I'm happy to add them if you know some. Otherwise we can add cases whenever we encounter new statuses.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually I just found a new case when someone renames a file

Copy link
Owner

Choose a reason for hiding this comment

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

Hmm yeah I'd rather not introduce a feature that's useful 90% of the time but confuses or misleads the user the other 10%. Another problem related to covering all the cases is that it's not obvious to the user unless they analyze the code in depth whether the diff being shown is the diff against HEAD or against the staging area.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

the diff being shown is the diff against HEAD or against the staging area.

The diff is always against HEAD

I think this is quite a useful feature, I'm not sure what you mean by confuse or mislead in the other 10%. The actual git status of the file is displayed in the main fzf window.

Copy link
Owner

Choose a reason for hiding this comment

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

Sorry, let me think about it some more. In the meantime, would you mind figuring out the rename case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah I already pushed a fix for that yesterday :)

Copy link
Owner

Choose a reason for hiding this comment

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

Full disclosure to be transparent and set expectations. Unfortunately, I am still against merging this as is. The code you wrote is great. Your idea is innovative. I really appreciate how much you've really owned this code and have been receptive to my feedback. This would be helpful for many users for many use cases. What I can't stomach, however, is that the preview works inconsistently, ambiguously, in a way that might be misunderstood.
If I were using it and had modified file F on staging and the work tree, and now was preparing to commit my staging area, I'd want to see the diff of F on staging vs F on HEAD. However, if it instead is showing me F on the work tree vs on HEAD, I might be misled to make the wrong decisions. And vice-versa. Basically, it can be confusing, not intuitive to use, even be misunderstood. So I'm going to think about this for another day, but unless there's a way we can show both staging diff and work tree diff and make it clear which one they're seeing, I'm probably not going to merge this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah I understand, I agree the behaviour could be better. On the other hand some context is better than no context.

Feel free to close if you think it's not worth it.

Copy link
Owner

Choose a reason for hiding this comment

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

Thanks for understanding Quentin. I'm also disappointed by the technical limitations here and hope this doesn't discourage you from contributing to more OSS in the future. I know you and I would have been able to use it fine, but there are many other users who don't read the docs or aren't as familiar with git and as the author, I must account for their needs as well. If you figure out a way to show both staging and work tree diff, feel free to reopen!

@PatrickF1
Copy link
Owner

Hey @ovv I have an idea now! git status -vv can show both the index changes and the worktree changes. And if we can show both, then I'd be happy to merge that in. Dunno if you're still interested in working on this.

@PatrickF1
Copy link
Owner

@ovv A similar PR, #237, has been merged!

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