I would say “elected for the next commission”.
See also here.
(In case that helps 
)
Of course, the menu bar item is “Window”, not “Windows”. Sorry.
If you are referring to SourceTree, I find the Custom Actions feature quite useful:
The actions then can be called from Menu bar > Actions > Custom Actions.
This is what I see:
Ah, I see. I get your menu when I start ST and only the repo selection window is open.
You have to open two windows (two repos) to get the Merge All Windows menu item.
Edit: But wait, your menu says you have two repos open…?! 
By any chance, are you on an old OS (10.11 or 10.10)?
If yes, then you probably won’t see the tabs. It seems SourceTree uses Sierra’s tabs feature.
Yes, I’m on El Cap. So at least now we know!
Thanks.
One thing I like about GitGub Desktop is that it automatically "checkmarks" all new, deleted, and changed files. But if I uncheck one or more files, it remembers that, and won't automatically checkmark those files.
It seems that SourceTree automatically checkmarks all changed files, but not new and deleted files.
Is there a way to get SourceTree to work like GitHub Desktop does, in this respect?
Thanks.
Personally I prefer to checkmark every file manually. (I often add files which shouldn’t be committed, but are not yet in the .gitignore.) So, I have never investigated that.
I thought that the preference “Select all files when selecting Commit” should do that, but apparently this is not the case. I will look up later and see if I find a solution.
What you always can do, is checking the “Unstaged” box, which will stage all files:
Thanks. Most of the time, I agree with you. But when working with this KM Macro Repository, I want it to automatically select all files.
No big deal, just one more thing to remember.
If needed, I can always make a macro for it.
OK, I got it now:
The preference “Select all files when selecting commit” is for the log view (“History”) only:
When you click a previous commit in the log view and that pref is set, then all files of that commit are auto-selected. I.e. on the right-hand side the diffs of all files are displayed.
If the pref is not set only the first file of a commit is selected when you click a commit in the log view.
1 Like
I use a VCS for Keyboard Maestro’s source (Subversion). Then I have daily backups and with offsite rotating disks.
Keyboard Maestro itself includes revisions on a daily basis. You can also sync your macros to Dropbox and then Dropbox will automatically keep revisions for you (might be a paid feature).
I personally also have a system which permanently saves a daily copy of my macros and shows me a diff of the macros since yesterday - but this is more to detect any bad changes I might accidentally cause to Keyboard Maestro as I am developing it (for example, accidentally erasing all the custom icons or something like that).
I don’t have any real plans to add more VCS support to Keyboard Maestro per se.
See, I knew you were a professional. 
I don't have any real plans to add more VCS support to Keyboard Maestro per se.
If I thought you might be thinking of doing this, then this topic wouldn't exist. 
Keyboard Maestro itself includes revisions on a daily basis. You can also sync your macros to Dropbox and then Dropbox will automatically keep revisions for you (might be a paid feature).
The problem with this is that the revisions are in one huge file. Did the file change? Probably. Can you figure out which macros changed, and what parts of them changed? Well, yes, but not easily. And revert an individual macro back to a prior revision? Well, you and I can probably do this, but the average user certainly can't.
What I'm doing is breaking the macros and groups apart into individual files. Much easier to see what changed. I also happen to save them as JSON files because (IMO) they're easier to read than plists. (I'm not suggesting that KM should use JSON files - I'm just saying that for this particular situation, they're easier to read.)
This is indeed true. I already caught myself editing a macro in the JSON repo and then importing it to KM, instead of editing it in KM Editor and exporting it
Especially with macros containing styled text with image data the JSON format is more comfortable to read than the XML, since it doesn’t hard-wrap lines:
JSON: 1 (long) line:
XML: 2564 lines:
(But, for the same reason, embedded scripts are easier to read in the XML.)
1 Like
I want to put my Keyboard Macros under version control (using Git and SourceTree).
However, I noticed that assigning a single hot key to an existing macro, after my initial commit, results in a huge delta, where I expected only a few lines at most.
I'm using an export of my macros (.kmmacros file). Am I doing it wrong? Or are my expectations wrong?
Personally, I gave up on using version control with KM. Just too many things that didn't work the way I wanted them too. But good luck to you!
2 Likes
If I’m putting a bunch of exported .kmmacros files under git control, I do get line deltas. This for example is the change of a hotkey trigger:
I'm with Dan on this one.
Thank you for sharing your experience guys.
Seems like I should not waste any time on this...
How do you make backups of your macros? (If at all?)
I guess I either rely on my Time Machine backups (which I run via KM so I can run them every other hour, and also mount and unmount my external drive), or make a copy before I edit something I'm worried I'll mess up.
The one thing you have to worry about, when making a copy, is if the macro is called by another macro. If you end up reverting to to the copied version, make sure to paste the actions back into the original macro.
With all that said, I have a thought I might explore, and get back to everyone.
1 Like