git rebase --onto master HEAD^ HEAD ;
git checkout $machine ;
git merge master

Which you would execute after making a tweak that should happen on master. The problem is making this work atomically with respective to merge failures. I suppose you would have to keep clone .dotfiles from another repository and do something like

git push ;
pushd $origin_dir ;
git rebase --onto master $machine~1 $machine~0 ;
git checkout $machine ;
git merge master ;
popd ;
git fetch ;
git reset --hard $machine origin/$machine

This would immediately convert the commit you just made into a commit on master, merged back to the machine branch.

Another reason it’s unfortunate is that mixing cherry-picks with merges leads to many more spurious merge conflicts than you’d get with either a pure cherry-pick workflow or a pure merge workflow. Merging a branch containing commits A and B with a cherry-picked A′ will result in a conflict if B depends on A. (Even if you try to get around this once with merge -sours, it will come back to bite you next time you really have changes to merge in.)

One way to solve this problem would be, after cherry-picking some commits onto master, to go and replace the original copies with merges of master into the machine branch. This requires non-fast-forwards of the machine branch, but you’re probably okay with that since you’re its only user.

Perhaps a better way would be to script the operation of {commit something to master and merge it to the machine branch} atomically without leaving the machine branch.