crs-al-language-extension
crs-al-language-extension copied to clipboard
waldo1001
renaming of files in a multi-root workspace : but it works :-)
Using a multi-root-workspace, using the git rename option. The output says:
28.11.2019, 09:56:41 - Warning: can't rename with git because of multiroot workspace issues. If you want to rename objects, it's best to do it in a non-multiroot environment.
28.11.2019, 09:56:41 - Rename file from Cod50915.GOBLicenseCheckSubscriber.al to Cod50915.GOBMDELicenseMock.al
Is this actually still needed? I checked 20+ instances where we renamed objects, resulting in a git rename by Your extension. All instances were a success.
I'll check with latest version, but I'm afraid so, yes ... multiroot, this "git mv" could result in empty files .. which is very frustrating...
So, in case of multiroot, i'm not renaming with "git mv", but with a classic rename, which indeed works... .
I am under the impressoin that a proper mv happened, although Your extension handled the renaming.
This is one example, properly done - though the output says it did a normal rename:
Maybe VS Codes git integration just got smarter? ' Cause if YOU did not do git mv... something did...
Had to rename some folders in a .NET repo today, used VS Code for the fun of it. Same here: did no git mv but just renamed the folders. Same result, have a proper history and no add/delete. So I guess You can simply test some scenarios with AL file handling by Your extension. If this looks good, maybe drop the feature?
EDIT: did it again, looked more closely now. -> rename results in unstaged add and unstaged delete. Staging both results in a staged result similar to a mv. I am pretty sure that is not what happened in the past, I like it a lot, though.
Ahoi Eric!
So it was rename time also on our side! I followed the comment saying : it does work automatically - no worries on git rename. And indeed. It worked out for me! >1000 Objects renamed...history kept - everybody happy!
Great - thanks for the feedback! So I assume you did NOT use my "renamewithgit" setting, and you "staged" all changes before you commited them to git?
Great - thanks for the feedback! So I assume you did NOT use my "renamewithgit" setting, and you "staged" all changes before you commited them to git?
Correcto! no renamewithgit was used.
I'm thinking of removing the "renamewithgit" and add a "git stage" at the end of a "rename all" command .. makes sense?
I wouldn`t -> it is no guarantee. One more change in the same commit for one affected file and that file will have a "broken" history regardless. This is something where You will simply have to KNOW how to handle git,
yeah, you're right .. but I guess removing the "renamewithgit" makes sense nevertheless.. .
May be i could just raise a confirm-message - or just an "information"-message ;-).
I'll think about it...