Renaming source files from outside with git ('git mv' for example) is recognized from the toolboxes 'project' tab, but this information will not be propagated to any open editor tabs. Even if the file in question had been saved beforehand, the tab name remains the same. You can even edit the bogus file further, but when saving it, it will be recognized as missing.
It works if you rename the file in Wing's Project manager, but not if done outside of Wing. It might be possible to try to look at the status information to determine a move was done outside of Wing, but we're not currently doing that.
It works for the project manager, but not for git. git mv would remove the file and re-add it to git's stage. After performing renaming in Wing, the file is simply missing. This is a problem if you like to separate version control from IDE, because the new file is simply unversioned and might be filtered out by for example another GUI used for version control (on Windows TortoiseGit with a respective option comes to mind).
To me, the one significant point for handling version control inside the IDE is the IDE's superior knowledge about his own project structure in case of renaming/moving/deleting files (essentially a catch-22). It follows that this is precisely the case that it should handle with excellence and transparency for git and itself.
Do you have Wing Pro or Wing Personal? If Wing Pro, have you disabled the git integration? Wing Personal doesn't have integrated support for revision control so I think it would do what you're describing, as would Wing Pro if you've disabled version control. Otherwise it should use git to rename if you rename something in the Project tool and it tracks this also in the editor. If you do have Wing Pro with version control enabled and this is not working, could you please send in a bug report from the Help menu immediately after a failed rename, so we can see if there is something in the log to explain it?
Problem was a missing git executable, mentioned in configurations 'Version-Control->Git'. It contains a generic entry named 'Git'. Browsing there for the executable defaults to .py as file ending. This is not the problem per se, but together with 'Enable built-in version control' from the configs parent entry I got the impression, the whole git is bundled with wing and called by some internal wrapper. After adding the correct executable things work as intended. Maybe the dialogs acceptation could block, if no executable can be found and 'Always Active' or 'Active if used by project directories' has been selected?
Great, I'm glad that solved it. I think the use of wrong extension in the file dialog should be fixed in our next upcoming release (there's a general fix for doing that wrong on Windows, anyway). We use the git executable and not a git API because it ends up matching what people are doing on the command line and thus works more often. Sorry about the problems!
Comments