arubdesu/autopkgMacTechArticleMissingParagraphs.txt

## autopkgMacTechArticleMissingParagraphs.txt
MOTIVATIONAL SPEECH (JUST KIDDING ABOUT NANO)
Now we'll transition into affecting change for the better in our open source world. For any number of reasons, Autopkg isn't seeing contributions from all corners of the world that are taking advantage of it, and I'd like to help clear up what may be some common barriers to entry. Using version control and code-sharing sites can certainly present a challenge to beginners, so I’d like to help folks get past those initial workflow difficulties. In the process, I'd also like to instruct folks using tools like Munki(2) how they might best pitch in to improve and get the most benefit out of others recipes.
I've recently been far too well known for snarkiness, and that extends to my opinions relating to interacting with version control, and in particular on autopkg's home, GitHub. With my lack-of programming savvy in general I'm probably not really one to cast stones, although really, no greps before awks, c'mon people, get with it, and use vi like the cool kids. (Seriously, nano?)
In truth, anyone who has written, or can read and mostly understand a script, or even folks that can just run scripts should be considered contributing to open source, and respect themselves as such. We're all engineers when going beyond what’s handed to us by the vendor of the platform we work on, so I'd like us on the IT side of things to start shaping up to the expectations more established software developers would expect when working with us. That starts with being wary of Git's power, but ready to forge ahead with how to best interact with a repo on GitHub. I'll try to give a quick tour of the 'levers' autopkg pulls when interacting with GitHub, and discuss the practical ways people can browse Github and even go so far as to contribute in an effective way.
HOW IT’S MADE
Autopkg goes so far as to even tell you it's 'cloning' the repo when you do a repo-add. This is the git term for taking a remote folder of code (in this case hosted on GitHub) and copying it down to your computer, where autopkg will work with and manage it for us. This isn't too different than, in the case of the nmcspadden-recipes repo, going to https://github.com/autopkg/nmcspadden-recipes and clicking the download button on the right and unzipping it to the correct location, but in a more maintainable way. If you're behind a poor internet connection or otherwise paranoid about future access to code you find on GitHub, you can download anything you’d like to keep a copy of in this way. There's also repo-update, which performs a git 'pull', which actually has two components: first it fetches the changes, then it performs a specific ‘merge’ (way of integrating the changes into what you already have) called a fast-forward, as it is in a direction straight ahead from where the current state of the code in that repo was.
	MOTIVATIONAL SPEECH (JUST KIDDING ABOUT NANO)
	Now we'll transition into affecting change for the better in our open source world. For any number of reasons, Autopkg isn't seeing contributions from all corners of the world that are taking advantage of it, and I'd like to help clear up what may be some common barriers to entry. Using version control and code-sharing sites can certainly present a challenge to beginners, so I’d like to help folks get past those initial workflow difficulties. In the process, I'd also like to instruct folks using tools like Munki(2) how they might best pitch in to improve and get the most benefit out of others recipes.
	I've recently been far too well known for snarkiness, and that extends to my opinions relating to interacting with version control, and in particular on autopkg's home, GitHub. With my lack-of programming savvy in general I'm probably not really one to cast stones, although really, no greps before awks, c'mon people, get with it, and use vi like the cool kids. (Seriously, nano?)
	In truth, anyone who has written, or can read and mostly understand a script, or even folks that can just run scripts should be considered contributing to open source, and respect themselves as such. We're all engineers when going beyond what’s handed to us by the vendor of the platform we work on, so I'd like us on the IT side of things to start shaping up to the expectations more established software developers would expect when working with us. That starts with being wary of Git's power, but ready to forge ahead with how to best interact with a repo on GitHub. I'll try to give a quick tour of the 'levers' autopkg pulls when interacting with GitHub, and discuss the practical ways people can browse Github and even go so far as to contribute in an effective way.
	HOW IT’S MADE
	Autopkg goes so far as to even tell you it's 'cloning' the repo when you do a repo-add. This is the git term for taking a remote folder of code (in this case hosted on GitHub) and copying it down to your computer, where autopkg will work with and manage it for us. This isn't too different than, in the case of the nmcspadden-recipes repo, going to https://github.com/autopkg/nmcspadden-recipes and clicking the download button on the right and unzipping it to the correct location, but in a more maintainable way. If you're behind a poor internet connection or otherwise paranoid about future access to code you find on GitHub, you can download anything you’d like to keep a copy of in this way. There's also repo-update, which performs a git 'pull', which actually has two components: first it fetches the changes, then it performs a specific ‘merge’ (way of integrating the changes into what you already have) called a fast-forward, as it is in a direction straight ahead from where the current state of the code in that repo was.