Git version control, whether at the GitHub site or at the command line is ostentatiously color-coded. How do red-green color blind users (a common issue for Engineers) deal with this? Any suggestions for discussing how to use the alerts and coding as in the following screenshots aimed at a potentially color blind audience? Thanks in advance!
People often don’t realize how powerful GitHub’s gist pasting service is. It’s more than just a “paste” site. Gist offers a full version control system extension to GitHub’s main site. I’ve been working on developing version control training materials and gist is a great way to introduce the fundamentals.
Many gist users know that the site offers you pushbutton convenience to paste one or more files. You can create open gists and “secret” ones hidden from public view. Gist also lets you fork, revise, and explore diffs between revisions.
For example, you can work in groups when writing. Collaborators can fork and make changes to offer content feedback. You can then use diffs to see what edits were made.
Here are some diffs from a recent Raw String proposal I worked on:
And this is the corresponding “rich diff”, which is slightly prettier:
And there’s a lot more you can do with gist. That’s because gists, as version control repositories, can be cloned to your computer, modified, and pushed back to GitHub. This means you can, for example, set up albums of pictures or host an easy-to-distribute zip file.
Each gist URL is a repository’s address:
git clone https://gist.github.com/erica/7cd24c6ab2f737735a9ab2b95628c549
As a gist’s owner, you have commit privileges, allowing you to edit your gist from your computer.
The command line enables you to add binary files that you can’t from the web interface. I grabbed a bunch of kitten pictures from Pexels and added them to my gist. A nice way to create simple albums:
If you click “Download ZIP” at the top right, GitHub zips up the repository contents (in this case five kitten PNGs) and copies them to your computer. This is not cloning; the zip file just stores the source files, not the full git repo.
It’s just as easy to host an archive file. When you have an Xcode project or playground that you need to share, Gist provides a great intermediate service alternative to iCloud or Dropbox. If you need privacy, use the “secret gist” button when creating the gist.
This isn’t, of course, the end of what you can do with gists. Because each gist is a git repository, you can perform all the same commands you would in any git repo. Gist, of course, has a limited interface, so you won’t be able to, for example, switch between branches from the gist website. On the other hand, you can perform other tasks that don’t depend on a GitHub UI like listing diffs:
% git diff cb9271da5070f11602d3ab436a05fb9705409fd2 diff --git a/raw.md b/raw.md index 8ed7306..ea4b5ed 100644 --- a/raw.md +++ b/raw.md @@ -104,9 +104,8 @@ Escaping hinders readability and interferes with inspection, especially in the l ### Candidates -A good candidate for raw strings: +A good candidate for raw strings is non-trivial and is burdened by escaping because it: -* Is non-trivial. * Is obscured by escaping. Escaping actively harms code review and validation. * Is already escaped. Escaped material should not be pre-interpreted by the compiler. * Requires easy transport between source and code in both directions, whether for testing or just updating source.
I think GitHub’s gists are pretty awesome. And now, at least for me, they’ve gone from handy but mindless pastes to something really special.
Do you have a special way to use gists? I’d love to hear about unconventional ways to use this utility site to push boundaries and introduce new functionality. Drop a comment or an email and let me know.
For a little while, I’ve been using emacs as my git editor because I strongly feel that vi is something that should happen to other people. It’s been fine but not everyone loves emacs or likes the debris it leaves in its wake. So I thought I’d try out TextEdit instead.
After a little testing of approaches, I first tried out this:
git config --global core.editor /Applications/TextEdit.app/Contents/MacOS/TextEdit
I picked this rather than some of the other approaches because it’s straightforward in launching the app. There’s one problem though, which is that git doesn’t pick up on the fact that a file has been edited and closed when the application remains active:
% git commit --amend
hint: Waiting for your editor to close the file...
(...waits forever...)
The commit completes and works when I quit TextEdit but I don’t like to quit the app each time I update a commit, especially if I have other files open. The amended commit does complete on quit:
% git commit --amend [master 59a0934] Testing TextEdit! Author: erica <erica@ericasadun.com> Date: Thu Jul 12 08:02:26 2018 -0600 1 file changed, 3 insertions(+), 1 deletion(-)
So I changed my approach. I turned to open instead:
git config --global core.editor "open -W -n"
TextEdit is open‘s natural environmental editor for text. You don’t have to specify more than open for git to work with the right editor.
This approach uses two tweaks. When you launch an app with open, the -n flag instructs open to launch a new instance of the application even if one is already running. You may see two “TextEdit” icons open in your dock, for example.
Combine -n with -W and you have a slightly better solution. The -W “wait” flag tells open to keep waiting until the launched application has finished running. This allows git to to wait “for your editor to close the file”, which you do by quitting TextEdit. Sure, I’d much prefer that TextEdit run using a “single file” mode, but this isn’t a bad solution.
Sadly, I couldn’t find any undocumented launch flags to make TextEdit run in single file mode and while it’s easy enough to write a Mac app that edits a single file at a time and quits on closing, it’s not a practical solution for everyone.
Is there a way to automatically propagate “done” back to git without ending a TextEdit process? I couldn’t find one. If you have a better idea, please let me know.
Over the past few weeks, my Mac mini has been getting less and less responsive. The kernel_task has been spinning up taking up ridiculous amounts of CPU time and dragging my system to its knees.
I did what anyone would: I ran hardware diagnostics (passed). I ran SMART diagnostics (passed) and then I web searched the hell out of the interwebs, and there I found an unusual suggestion. Several sites suggested that I may have built up dust accumulation in my mini and that the fan control was trying to mitigate this.
Fortunately, I’m one of the lucky ones (for very low values of “lucky”) with a self-serviceable 2012 Mac mini instead of the upgrade a few years later that removed the service hatch. (*shakes fist*. *darn you Apple.*)
I opened it up and sure enough it was pretty dirty in there. I vacuumed and then I used compressed air to finish (after finding the child who had “acquired” it for an “important project” several months ago and never returned it). I performed a thorough vac and dust of the work area where it rests along with my many backup and external data drives.
Plugged it back in and for nearly a week so far I have not had the same issues reoccur. It seems a tiny bit black magic but it also seems to be working (fingers crossed).
I thought I’d write up a quick post to share my experience and see if anyone else has been through this and has advice or suggestions. For me, it’s like having my Mac back again. I still need a refreshed mini (hint Apple hint) but I have serious concerns about buying one without a self service hatch.
Apple’s move away from self-service products has cemented its appeal as a “computing appliance” provider but it also means expensive service calls for any problem. Much as I’d like them to give us a Mac Pro Lite, at a lower price point than the Pro and a higher one than the mini, with lots of configuration options, I just cannot see that kind of product ever existing in today’s Applesphere.
A lot of us mini owners cling tenaciously to our six-year-old hardware (or, for some, 4 year old), but I’ve seen no indication that the mini has a future at all in the lineup. If it’s not a product appealing to the BMW owner set or essential for internal Apple use, I don’t really see it having a place in Apple’s marketplace.
One indication against this gloom is Apple’s magnificent iPod line, which has at least gotten semi regular updates. The iPod touch is about the best value you can buy with an Apple logo on it outside of the core iPad released this past March. Both fit into if not BMW owner appeal, then at least BMW owner’s kids appeal. I just don’t see the Mac mini doing that.
Is the mini dead forever? I’m not sure. I like bringing my own displays, my own mechanical keyboard, and thousands and thousands of dangled USB add-ons. That’s what a desktop does for me and why the (self service) mini is the perfect fit.
If you want to point at one change Apple made that said to me: “No mini for you, move to the left!” a la that Seinfeld episode, it was the death of the escape key. The escape key philosophically services a self-reliant power user. And I’m just not sure that Apple is in that market anymore.
Will I get my mini pro? Probably not. Will there be a paradigm shift so profound that customized dev systems can co-exist with mechanical keyboards using a new desktop system? Maybe. What do you think? Are you a mini devotee? Share your thoughts.