Sven Schmidt alerted me to the fact that you can check in Package.resolved to pin Swift package versions in Xcode-managed projects if you add the file from within the generated project.xcworkspace file in your .xcodeproj bundle:
Since COVID-19 doesn’t seem to go away any time soon, I figured I might as well continue with #IndieSupportWeeks to show you what I use and can recommend.
A dev tool I use on iOS is Working Copy. Usually, I don’t interact with my project code at all from iOS, but when I do, I check git stuff with this app.
Over the past 10 years or so I’ve tried a couple git clients for light work on mobile, but Working Copy sticked with me ever since I was participating in the TestFlight beta.
For a casual git fan-person, Working Copy’s settings might be a bit overwhelming, but for developers, I think this is a very fine app to browse, search, push and pull, and even commit changes.
Now the “commiting changes from mobile” part in someone’s daily workflow is utterly confusing to me, because I cannot imagine what that’d be like on an iPad, say.
I have edited posts on my website this way to fix typos. That went well. I also used it for light maintenance of Open Source projects. But I haven’t tried to commit to my Swift projects, because I don’t see how editing Swift files without a compiler would be a good idea. Then again it’s not my job to figure out user personas for a mobile git client – I’m here to tell you that if you’re in the market for such a tool, Working Copy is good at that.
The one thing I can testament to is that it works without a hassle, and it works well. That’s not much, but that may also be all you truly care about.
Working Copy is a free download + a $19.99 one-time in-app-purchase to unlock all the features. It also has a 4.9-star rating on the App Store, so, wow!
For about two years now I still use Brett Terpstra’s gitlogger to store my daily git activity in Day One. As of late, it ceased to run properly. Turns out some messages to log contain fancy characters like real apostrophes, ’. To fix this, add the following statement to the launchd configuration script:
I use Brett Terpstra’s little Ruby script called “gitlogger” to write git commit messages from selected repositories into my Day One journal once a day. My commit messages tend to be a bit longer when I work on projects which really matter. Unfortunately, gitlogger wasn’t intended to handle multi-line commit messages. Every commit message resides in a list item. But if you know Markdown, you’ll know this markup won’t render as expected:
After CriticMarkup was released with a toolkit including Sublime Text 2 theme and commands, I simply ported the easy stuff to TextMate. Since Sublime Text bundle files are heavily inspired by TextMate (to ensure compatibility with the popular Mac all-purpose editor, I suppose), this wasn’t a very complicated task.
I put my personal nanoc boilerplate setup on GitHub. Maybe you find the deployment process useful.
Deployment Process
I assume you’re public html folder is called htdocs/ and you can create new folders below your domains folder but outside htdocs/.
I also assume you use my Rakefile: upon rake build it will checkout the branch ‘deploy’ and put all files from output/ in there. Uploading from ‘deploy’ to the production server will only copy the HTML output, not the nanoc setup.
Initialize bare production git repository on the server:
git init --bare ~/doms/example.com/git
You’ll want automatic updates when you push to the server. Use git’s own post-receive hook:
# add to ~/doms/example.com/git/hooks/post-receive
echo "Updating website ..."
cd /the/full/path/to/doms/example.com/htdocs || exit
unset GIT_DIR
git pull origin
echo "Update complete."
Make it executable:
chmod +x post-receive
Initialize git repository in htdocs/. This will point to the bare
repository on the server and check out the current version:
# given you're in ~/doms/example.com/htdocs
git init
git remote add origin ../git
# setup branch to pull from:
git config branch.master.remote origin
git config branch.master.merge refs/heads/deploy
Setup production server locally:
git remote add production ssh://user@example.com/~/doms/example.com/git/
git remote show production
Commit changes locally and put them on the server:
git commit
rake build
git push production deploy
You can push all branches via git push production to backup your code.
Only the branch ‘deploy’ will be visible to the public.