nicowilliams

Guide to Git Noobies and would-be Power-Users

This is an attempt at a concise guide to git that can help noobies and power users think their way around git. We assume the user knows a little bit about Unix filesystems or, alternatively, programming.

We explain the most essential git concept and then explain a second tier of concepts in terms of that one essential concept, then a third tier of concepts that power users must know (e.g., rebasing). This approach should give the reader all the mental tools needed to make the most of git.

What this is NOT:

• this is NOT a git cheat-sheet (though there will be examples);
• this is NOT a guide for people who are new to computers in general.

nicowilliams

Warning: work in progress. Incomplete

People who have been in security a long time (or even not that long) know that some inputs should be treated as tainted. For example, environment variables from a user should not be used in a set-uid program, inputs from a different user should be validated, etc... Traditionally we say that the environment of a set-uid program is tainted and should not be used (or used with much care).

Therefore we want all set-uid/set-gid programs to treat their environment and user inputs as tainted.

nicowilliams

I recently happened upon an implementation of popen() (different API, same idea) using clone(2), and so I opened an issue requesting use of vfork(2) or posix_spawn() for portability. It turns out that on Linux there's an important advantage to using clone(2). I think I should capture the things I wrote there in a better place. A gist, a blog, whatever.

So here goes.

Long ago, I, like many Unix fans, thought that fork(2) and the fork-exec process spawning model were the greatest thing, and the Windows sucked for only having [exec*()](http://pubs.opengroup.org/onlinepubs/9699919

nicowilliams

GitHub already stores wikis for repos as... git repos.  It'd be nice if they could be in the _same_ git repo, with a naming convention for the wikis' branches (just as with `gh-pages`).

And if GitHub were to git-back issues, as I mentioned in my previous gist, then all three things could be in the same repo, which would be very convenient.

nicowilliams

Issues should be just like wikis: git-backed.

The Fossil VCS stores sources, wikis, and tickets (what GitHub calls issues) in the same repo.  Well, so can git, of course, though currently only by convention.  GitHub already stores wikis in git.  Why not also issues?

nicowilliams

It took me a while to figure out a generic solution to this problem of
deepening XML document structure using XSLT.  I could not find general
solutions online (or in the two books on XSLT that I bought), and though
I never worked out an XSLT 1.0 solution that worked well enough, I did
find a solution that works perfectly with XSLT 2.0.

The idiom consists of a template matching <hN>s that applies templates
to all following-sibling nodes that are not <hN> nodes and whose
preceding <hN> sibling is the current <hN> (the content of this
section) and then applies templates to all following-sibling nodes that

nicowilliams

I discovered impress.js this week.  And S9 (Slide Show) and its impress.js template.  And Mimpress (an iOS app that lets one author and view presentations written in markdown and which use impress.js).

I suspect that Mimpress uses S9 under the covers, not just impress.js, as the presentation I wrote is compatible with S9 with the impress.js template.

I'm very happy with this turn of events.  Hats off to @bartaz for impress.js!