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

Tracking complexity over git mv #84

Open
KennethNielsen opened this issue Sep 16, 2019 · 2 comments
Open

Tracking complexity over git mv #84

KennethNielsen opened this issue Sep 16, 2019 · 2 comments
Labels
enhancement New feature or request

Comments

@KennethNielsen
Copy link

Hi and thanks for the tool.

I recently read the "put your code in a src folder" article by Hynek and found that I agreed with basically everything. So I moved the code. The problem then is, that when I run wily on the archive, it only shows me stats on the part the history that is after the move. It would be cool if Wily could follow the git renaming heuristic and track the files across a move.

If this supposed to work already and isn't a feature request, I'm happy to provide more debugging information.

@tonybaloney
Copy link
Owner

Wow, that would be a beast of a challenge to implement! 😄

It is also an awesome suggestion.

There are a couple of ways this could be implemented:

  1. A command to rename the indexed files/modules to the new paths
  2. A definition of rename heuristics within the index so that it follow the history of files/folders. I don't know very much about git's rename capability and the support from within the Python library that wily uses.

@tonybaloney tonybaloney added the enhancement New feature or request label Sep 17, 2019
@KennethNielsen
Copy link
Author

KennethNielsen commented Sep 17, 2019

@tonybaloney agreed that it isn't exactly simple. I was actually thinking something similar considering the two possible implementation pathways:

While I agree that 1 with something like a --formerly-known-as or --aka ;) option (which should of course work both for individual files and folders) is a more certain thing for an implementation, I will probably introduce some annoying special casing into, I guess, a quite central part of the implementation.

As far as 2 goes I can provide a bit of information. In git, since it doesn't track files, a move is a heuristic, so basically if git sees a file disappear and another appear and the are 80% content similar, it regards that a move and will show it as such when you look at the status before commit. I would therefore guess that it will also show it like that when you view history, but whether that is exposed in the python git module I'm not sure.

I would love to say that "I would like to work on this", which I would because I consider contributing to new codebases of cool tools a fun challenge, I'm afraid I have to little spare time these days.

I should also mention that I am not yet a significant Wily user, I just tested the tool after seeing you pycon talk and felt I should bring it up. So don't up prioritize it on my account ;)

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

No branches or pull requests

2 participants