No, I don't have any idea, and that scares me. I'll have to think about it.
1 Like
@DanThomas, thanks for the quick reply. I'd be glad to provide any additional information you might need as you think through this.
For anyone following along, Jim and I worked offline on this issue. He discovered that he no longer needed the macros that caused the issue, so we decided to just leave it alone.
If anyone else has this problem, let me know.
2 Likes
How can I suppress the final "Finished" dialog.
I'd like to automate the BU to happen in the early AM without having to address the "finished" dialog window.
Thank you
In the "Macro Repository Updater" macro, copy the Close the "Please Wait" dialog action as shown below, and disable the Have the "Please Wait" dialog indicate we're done action.
2 Likes
a great macro!. thanks very much @DanThomas
I was wondering if favorites (as in favorite actions) are saved in the repository. If not, would it be possible to add them ?
thank you
Thanks! No and no. 
But you could always add your own actions to do that.
1 Like
OK. Thank you Dan
Hi, I use the macro a lot and am grateful. I understand that it was written in 2019. What is the difference in outcome between your macro and export all macros as folder in the KM menu ?
thank you
1 Like
Hopefully nothing of significance.
3 Likes
thank you Dan
Is there a difference in convenience, access, automation? Why use this over the built-in Export function?
Separate files for each macro.
2 Likes
Dan, not sure if you're still reading here, but I'm finally investing some time (after some painful sync-related lost work) in figuring out how to get your macros and git going for my collection. I have the basics working well now, I think, and have tested changing a macro and watching it roll into the repository.
My question—as a total git neophyte—is this: How do I use the repository to go back in time? Let's say I have Macro X, and it's in the repository. I then make a bunch of changes over time, with each winding up in the repository. But then I realize I've made a logic error, and need to go back to the version before I started making all the changes.
I can see all the changes in git (via SourceTree), but what's the actual mechanic of getting the original version back from the repository into KM (via your import macro, of course, but how do I get the old version, not the latest one that was saved when I last ran your export)?
thanks;
-rob.
That's a good question. I'll be thinking out loud here, so bear with me.
The first thing I'd do is make a copy of the folder that has all the macros, including the git repository (the git repository is a hidden folder called ".git"). That way you can put everything back if you/we mess up.
Do you happen to have a Time Machine backup that has the version you want? If so, that would be the easiest way to get it back. Just restore the folder for the macro. Then import it into KM. If it's what you want, you can do another SourceTree commit and you're good to go.
It gets more complicated if that doesn't work. Git doesn't make it easy to revert just one file/folder. It's totally doable, but it's more complicated than it should be.
So before I write up those steps, let me know if you have a backup, and that works for you.
Well, it was a theoretical question as it hasn't happened yet, but I have run into this exact scenario in the past. At that point, the way I handled it was whenever I started making substantive changes, I'd duplicate and disable the macro. At the end, I'd wind up with like 10 versions just sitting there, waiting to make sure I did what I meant to do :). I was hoping git might help make that process simpler if I just wrote a change to the VCS each time. But it sounds like not.
I would have a Time Machine backup, so that sounds like the route I'd take ... I was just hoping it'd be nice and easy with all the change data sitting there in git. I did some web searching, and it seems like this post has the process I'd follow using git?
-rob.
Wow, I didn't know you could do that! Of course, I haven't tried it, but it looks good.
You'd laugh at the steps I've used before to do this. So learning this is really helpful - thanks!
I'll experiment a bit later today with a test macro and see if it works. But if so, this could be exactly the solution I needed.
-rob.
Good idea to practice. By the way, git doesn't care about file timestamps. It compares the file's size and contents. Just thought you should know.