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

Commit finding could be improved #32

Closed
hakunin opened this issue Aug 23, 2016 · 2 comments
Closed

Commit finding could be improved #32

hakunin opened this issue Aug 23, 2016 · 2 comments

Comments

@hakunin
Copy link

hakunin commented Aug 23, 2016

Hey guys,
I noticed I left a console.log in my PR so I removed the line and asked git fixup to tell me where it was introduced.

There were threee candidates

  1. first one touched the file but it didn't introduce the line. The diff shows that the changed lines were nowhear near where I added the line that I wanted to remove
  2. then there was the commit where I added the line (yay!)
  3. and third one touched the file as well, but didn't introduce the line either (although it modified lines around it)

I don't know how easy it is to tweak this, but it seems like the tool just shows the commits where I touched the file in this case instead of using git blame that would point to the right line straight away.

@hakunin
Copy link
Author

hakunin commented Aug 23, 2016

Just tried the commit guessing two more times and in case of a one line edit it wasn't even able to guess the commit where I added that line (it wasn't even in the candidates).

@keis
Copy link
Owner

keis commented Aug 23, 2016

Hi @hakunin thanks for your feedback it's much appreciated

This script is tuned towards producing slightly more false positives in order to ensure the commit we want is actually included. With the assumption being that you most likely already know which commit you want or could tell at a glance. But a short list is of course desired as it's much faster to tab through and indeed the whole point of this script as otherwise it might as well be git log. Tuning it otherwise is simple but is likely to break other uses. The code should be simple enough to follow if you want to play around with it.

In particular it uses 1 surrounding line for git blame this in order to catch fixups where you add items to a new line separated list. Or changing the end of functions in python code. A secondly it always includes the latest change to every file that is changed which is arguably a pretty blunt tool but that helps cover common f-ups like missing includes or a missed rename that happen all over the file.

If you have any examples where the script fails that you could share that would be great :)

@keis keis closed this as completed Mar 10, 2021
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

No branches or pull requests

2 participants