You remember this
post? I tried to warn you that when
v16 comes out, there will be a new code rule that will check your filenames –
and you’ll have to (if you don’t disable it) comply with the file name
convention of Microsoft. If you don’t
automate your file naming, then you’re in for some .. uhm .. challenges. I just made sure that the automation of the
filenames complied with Microsoft’s rules .. .
I need to correct my
store in that post though. I had been
working on this “RenameWithGit” setting, which didn’t work with
multiroot workspaces and had some other stability problems. Only after my post – thanks to a reaction
from James Pearson on twitter – I learned
there is a much simpler way to do this.
First of all …
Indeed – just forget
I ever built it. I’m actually thinking
of taking it away in the near future. I
already removed it from all my workspaces, and I strongly recommend you to do
the same. It doesn’t work like it’s
supposed to work .. and I’m embarrassed enough about it ;-).
There is only one
word you need to remember ..
All you have to do
after you renamed all objects is to stage the changes. That’s it.
And then you’ll see that actually everything is just fine.. . I found some kind of description about this
ability here: https://stackoverflow.com/questions/29706086/how-to-stage-a-rename-without-subsequent-edits-in-git.
If you’d rename a
file, you will get a delete and a new untracked file in Git, like you can see
When you stage the file
in vscode, you get the rename:
What it actually
does in a stage is it will compare the files, and when more than 50% is the
same, it will indicate it as a “rename” it in stead of deleting the
old name, and creating a new file.
And yes, indeed ..
I have been immensely wasting my time on the “RenameWithGit” setting
Well .. It’s
actually good practice to always “intentionally” stage. You must have seen this message already:
In VSCode, it’s
called “smartcommit”. But
honestly, in my opinion, the smartest commit is an intentional commit. I don’t like this message, and I switch it
off by setting this up in my user settings:
I’m not forcing you
to do so .. but this way, you can easily check in VSCode if the rename of the
file, was actually a rename of the file
– and not deleted and new files. Like it
Quite the same as I
mentioned in my previous post about this – but a bit different.
Yep, I still recommend to do the entire
process in a separate branch. Of
course. It will give you a way out if
you messed up ;-).
The setup is actually very similar as in my previous post, only now with the “RenameWithGit” = false. To match the file name convention of Microsoft .. this is what I would use:
"CRS.ObjectNameSuffix": " WLD",
you could add the “RemovePrefixFromFilename” or
“RemoveSuffixFromFilename” – but make sure you set
up the mandatoryAffixes-setting in the AppSourceCop.json as well, for the
CodeCop to accept the removal of the prefix or suffix.
commit is there because you might want to revert after a failed rename-attempt.
is the same “Rename All” function I talked about in my previous post:
will rename all files of the current active workspace (the active workspace is
the workspace of the currently activated document (file)) – not all
workspaces. So you probably have to do
this for all workspaces separately.
Thanks to the “RenameWithGit” to false, I expect no
mistakes. I was able to apply this to
+6000 files today .. so it’s tested, I guess ;-).
is THE step I was talking about earlier.
Here you can check if the rename was successful – all renamed files should indicate an “R”, like:
you see that – you’re good to go and …
commit, push and create a pullrequest to the necessary branch .. and you should
Yes indeed – this
flow does work in a multiroot workspace.
Do execute it for all workspaces separately though, like mentioned
before. That’s how I implemented it.. .
It’s a piece of cake. Really. So just do it, comply with the naming convention, and don’t feel like you’re cheating on Microsoft ;-).