When you upload a plugin to WordPress.org’s repository, it does some pre-flight checks to make sure the code is okay. More than once it’s caught a missing ; for me. But one day it caught this:
I stared for a moment, Googled to be sure, and sighed when I figured out that what was happening was my library was a PHP 5.6+ version and that didn’t pass the 5.4 checks.
Regardless of how annoying this is, it’s not too hard to fix. No, I’m not going to tell you how to avoid the scan, nor am I going to talk about the stupidity of the scan. Instead I’d like to tell you how to get around this problem.
And for what it’s worth, this is great. I have it download all my libraries. Then I have it run a script to copy over just what I need to my aws folder and I have Git and SVN ignore the vendor folder. Everyone wins! The problem is that Composer sees that my laptop is running PHP 5.6 and so it installed version
Fix PHP on Your Computer
Since I use Homebrew on my Mac, this is super easy for me.
$ brew unlink php56
$ brew install php54
Then when I re-run composer update it will install what I need.
The problem here, though, is that this is tied to a specific computer, and if a coworker downloads my stuff and plans to fork it, they’re SOL and merges fail and it’s sad times all around. So with that in mind, uninstall 5.4 and go back to 5.6.
If you have a problem with installing 5.6, run it this way:
I like this fix better. Put this above your require statement and you’ll force Composer to build based on PHP 5.4:
"config": {
"platform": {
"php": "5.4"
}
},
Now we’re cooking with fire. This works for everyone, it forces Composer to download 5.4 compatible libraries, and my very long transmission worked.
Is This Perfect?
Obviously not. There are going to be cases where your code absolutely has to be the code for PHP 5.5 and up. The latest version of the AWS SDK is v3, for example. But it’s for 5.5 only. I personally don’t feel there’s enough of a buy-in for PHP 5.5 and up yet to make an issue of it. And having no check at all won’t fly.
One thing I am personally bad at is version control. Oh, don’t get me wrong, I’m great decent at it for code at work, but I still have a tendency to cowboy code. Bad me.
Part of why is that I don’t want to have my stuff public. At the same time, I don’t want to pay Github while I’m learning, and I want a GUI. Why not overcomplicate my life! I’ll add on one more, I want a website where I can look at my changes all pretty like. Last time I did this via SVN, hated it, never used it, and walked away. This time I decided to use Git, and once I started using it via the command line, I realized how freaking awesome this was. And since I’m using CLI, I ran git config --global color.ui true to get pretty colors.
I should note that I use Coda2 by Panic and I love it. But. It doesn’t have an easy way to properly branch and tag in SVN or Git, which is something I’m used to having. And my master plan is this. Master will have the ‘live’ real code. The branches are releases. When a branch is ready to go live, I merge it with master.
Cart comes after horse, though. I had a hell of a time getting my own SVN crap up and running, but git was way easier. There was far less to mess with to install, since I’d already done it before. With Git, I don’t need to mess with svnserve or daemons, since git isn’t the ‘server’ where my code is stored, it’s just another repository/clone. It breaks my head sometimes, but this is a case where it’s going to be easy. Install any Git dependencies (on CentOS that means I ran yum -y install zlib-devel openssl-devel cpio expat-devel gettext-devel ) and then install from command line:
cd /usr/local/src
wget http://git-core.googlecode.com/files/git-1.8.2.2.tar.gz
tar xvzf git-1.8.2.2.tar.gz
rm git-1.8.2.2.tar.gz
cd git-1.8.2.2
./configure
make
make install
Done, and now I’m on 1.8.2.2. Upgrading is as easy as doing the wget again.
Stage Two: Make Repositories
At this point, the official git directions say you should make a git account, but after some pondering, I decided to put my repos in /home/myuser/gitrepos/ so I can easily add my repositories to my local computer. Everything is locked down via RSA keys anyway, so I can secure connect from my computers and everything is basic and simple and safe. If I want to make more repositories for other accounts, I can do it as a one-by-one basis. Right now I have no need for group stuff, this is a me repository after all. If I did, I’d use git’s directions for making a git user instead.
I made projects for my domains (ipstenu and jfo) and then one for my server (mothra). I hooked into them with Coda2, which is my app of choice, and I tested that I could get and push files. I’ll come back to this in a second.
Stage Three: Webify it!
Next up was webifying things. I want to do this, even though I’m putting it behind a password, because I’m visual and being able to see what I’ve got going on is helpful to me. I went with GitList because it looked nice. The drawback to these things is that if I used a shared repository (say /home/gituser/gitrepos/ for example) then I’d have to web-alias to the gituser instead of having it hosted as ‘Ipstenu’ … which is okay. If I was really making a full blown shared group, I’d probably buy gitstenu.org and point it there.
Awesomesauce! It works! Except for this error Unnamed repository; edit this file ‘description’ to name the repository. That’s easily fixed on the server by editing the description file.
Those initial repositories are for my non-public files, actually. That’s where I keep copies of the obscure shell scripts I run, stuff that isn’t web accessible. After I got those set up, I made repositories for my themes and my mu-plugins. This gave me folders like ipstenu-mu-plugins and jfogenesis-wp because I named the theme ‘jfogenesis’ for WordPress, MediaWiki, and ZenPhoto. Still this let me progress to …
Stage Four: Control
The whole reason I did all the rest of that was so I could do this, which seems redundant, but bear with me.
I checked out all the code locally, edit it, and push it back up to the repos on my server
On the webserver, I check out the code with a simple git clone to folder2 (trust me)
switch folder and folder2 (you know how to move things)
Checkout the new code with a git pull. If I want to checkout a specific version, it’s git checkout -b mysite-REL_1.0 origin/REL_1.0(It’s worth mentioning that I made a branch for everything at the start as REL_1.0 because reasons.)
And that’s it.
Stage Five: Updates
Here’s my current process.
Locally, I start work on my new version so I make a new branch: git checkout -b REL_2.0
Edit my files and add and remove them as needed:
git rm <filename>
git add .
Check them in when I’m done with the files: git commit -m "Editing foo and bar, replacing baz."
When I’m ready with it to be tested, I push it: git push origin REL_2.0
Everything tests well on the dev server(Just pretend there is one.)? Okay! Let’s merge!
Since this is just me running stuff, it’s pretty easy to keep track of everything. Having the website makes it easy for me to see what’s I last did and what’s changed:
Again, yes, I put the git website behind password protection. I may change this later, if I determine I never put anything secret up there. But right now, this is good for me. After a couple days of using it, I liked it a lot. Enough that, unlike my foray into SVN, I kept using it. It was easy for me to keep my code organized and up to date. If I had to update ‘live’ I could still use branches easily and roll things back painlessly. That’s pretty darn cool.
I’ve been banging my head on this for a while. It really did take me a year and reading lots of things to begin to understand that I was totally wrong. As with many things, I have to sit down and use them for a while to understand what I’m doing wrong, and what I need to learn. I finally had my git breakthrough. It’s very possible (no, likely) that I got some of this wrong, but I feel like I now understand more about git and how it should be used, and that made me more confident in what I’m doing with it.
Speaking as a non-developer (hey, sometimes I am!), I just want a command line upgrade for my stuff. This code also lacks a WordPress-esque click to upgrade, so I have to do a three step tango to download, unpack, copy, delete, in order to upgrade.(By the way, more software should have one-click upgrades like that, it would make life easier for everyone. I do know that the backend support is non-trivial, so I would love to see a third-party act as a deployment hub, much like GitHub is a repository hub.) The more steps I have, the more apt I am to make an error. So in the interests of reducing my errors and my overhead, I wanted to find a faster and safer way to deploy.(My previous job was all about deployment. We had a lot of complicated scripts to take our code, compile it, compress it, move it to a staging site, and then email that it was ready. From there, we had more scripts to ‘move to test’ and ‘move to prod’ which made sense.)
Since I already thing that automating and simplifying deployment is good, and all I want to do is get one version, the ‘good’ version, of code and be able to easily update it. One or two lines is best. Simple, reliable, and easy to use. That’s what I want.
Recently, Ryan Hellyer pointed out git archive, which he claims is faster than clone. I’d believe it if I could get it to work. When I tried using HTTPS, I got this: fatal: Operation not supported by protocol.. So I tried using ssh and got Could not resolve hostname… instead. Basically I had all these problems. Turns out github turned off ‘git archive -remote’ so I’m dead in the water there for any code hosted there, which is most of my code.
I kicked various permutations of this around for a couple afternoons before finally throwing my hands up, yet again, and looking into something else, including Capistrano, which Mark Jaquith uses in WP Stack. It’s something I’m personally interested in for work related reasons. Capistrano is a Ruby app, and vulnerability fears aside, it’s not very user friendly. At my old job, we used ant a lot to deploy, though there don’t seem to be ant tasks yet for Git. The problem with both of those is that they require you to pull down the whole hunk ‘o code and I’m trying to avoid that in this use case. Keep it simple, stupid. Adding more layers of code and complication onto a project that doesn’t need it is bad.
Finally I went back to git and re-read how the whole distributed deployment works. I know how to clone a repository, which essentially gets me ‘trunk.’ And I know that a pull does a fetch followed by a merge, in case I’d done any edits, and it saves my edits. Hence merge, and why I dig it for dev. At length it occurred to me that what I wanted was to check out the git repo without downloading the code at first. Well I know how to do that:
That brings down just a .git folder, which is small. And from there, I know how to get a list of tags:
$ git tag -l
v0.3.0
[...]
v0.8.0
v0.9.0
And now I can check out version 8!
$ git checkout v0.8.0
Note: checking out 'v0.8.0'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
HEAD is now at 8acc57d... set version to 0.8.0
Well damn it, that was simple. But I don’t want to be in a detached head state, as that means it’s a little weird to update. I mean, I could do it with a switch back to master, a pull, and a checkout again, but then I thought about local branches. Even though I’m never making changes to core code (ever), let’s be smart. Linus Torvalds flipping Nvidia the birdOne codebase I use has the master branch as their current version, which is cool. Then there’s a 1.4.5 branch where they’re working on everything new, so when a new version comes out, I can git pull and be done.(In this moment, I kind of started to get how you should be using git. In SVN, trunk is where you develop and you check into tags (for WordPress at least) to push finished versions. In git, you make your own branch, develop there, and merge back into master when you’re ready to release. Commence head desking.)
One conundrum was that there are tags and branches, and people use them as they see fit. While some of the code I use defines branches so I can check out a branch, others just use tags, which are treeish. Thankfully, you can make your own branch off a tag, which is what I did.
I tried it again with a non-Github slice of code: Mediawiki.(Mediawiki, compared to wp-cli, is huge, and took a while to run on my laptop. It was a lot faster on my server. 419,236 objects vs 10464. I’m just saying someone needs to rethink the whole ‘Clone is faster!’ argument, since it’s slow now, or slow later, when downloading large files. Large files is large.) Now we have a new issue. MediaWiki’s .git folder is 228.96 MiB… Interestingly, my MediaWiki install is about 155MiB in and of itself, and diskspace is cheap. If it’s not, you’ve got the wrong host. Still, it’s a drawback and I’m not really fond of it. Running repack makes it a little smaller. Running garbage collection made it way smaller, but it’s not recommended. This, however, is recommended:
git repack -a -d --depth=1 --window=1
It doesn’t make it super small, but hey, it worked.
Speaking of worked, since the whole process worked twice, I decided to move one of my installs (after making a backup!) over to this new workflow. This was a little odd, but for Mediawiki it went like this:
git clone --no-hardlinks --no-checkout https://gerrit.wikimedia.org/r/p/mediawiki/core.git wiki2
mv wiki2/.git wiki/
rmdir wiki2
cd wiki
git reset --hard HEAD
Now we’re cloning the repo, moving our files, resetting where HEAD is, and I’m ready to set up my install to use the latest tag, and this time I’m going to make a branch (mysite-1.20.3) based on the tag (1.20.3):
git checkout -b mysite-1.20.3 1.20.3
And this works great.
The drawback to pulling a specific tag is that when I want to update to a new tag (1.20.4 let’s say), I have to update everything and then checkout the new tag in order to pull down the files. Now, unlike svn, I’m not making a full copy of my base code with every branch or tag, it’s all handled by head files, so there’s no harm keeping these older versions. If I want to delete them, it’s a simple git branch -D mysite-1.20.3 call and I’m done. No code changes (save themes and .htaccess), no merging needed. And if there’s a problem, I can switch back really fast to the old version with git checkout mysite-1.20.3. The annoyance is that I just want to stay on the 1.20 branch, don’t I? Update the minors as they come, just like the WP minor-release updater only updates changed files.
Thus, I asked myself if there was a better way and, in the case of MediaWiki, there is! In world of doing_it_right(), MediaWiki has branches and tags(So does WP if you looked at trac.), and they use branches called ‘REL’. If you’re not sure what branches your repo uses, type git remote show origin and it will list everything. There I see REL1_20 and since I’m using version 1.20.3 here, I surmised that I can actually do this instead:
git checkout -b mysite-REL1_20 origin/REL1_20
This checks out my branch and says “This branch follows along with REL1_20.” so when I want to update my branch it’s two commands:
git fetch --all
git pull
The fetch downloads the changesets and the pull applies it. It looks like this in the real world (where I’m using REL1_21 since I wanted to test some functionality on the alpha version):
This doesn’t work on all the repos, as not everyone follows the same code practices. Like one repo I use only uses tags. Still, it’s enough to get me fumbling through to success in a way that doesn’t terrify me, since it’s easy to flip back and forth between versions.
Fine. I’m sold. git’s becoming a badass. The only thing left is to protect myself with .htaccess:
And to figure out how to get unrelated instances of git in subfolders to all update(Mediawiki lets you install extensions via git, but then you don’t have a fast/easy way to update…):
#!/bin/sh
for i in `find ./ -maxdepth 1 -mindepth 1 -type d`; do
cd $i
git pull
cd ../
done
And I call that via ./git.sh which lives in /wiki/extensions and works great.
From here out, if I wanted to script things, it’s pretty trivial, since it’s a series of simple if/else checks, and I’m off to the races. I still wish every app had a WordPress-esque updater (and plugin installer, hello!) but I feel confident now that I can use git to get to where my own updates are faster.
I’ve noticed a lot of people don’t really ‘get’ what version control is, or how it works. This is most evident when you watch the WP plugin repository.
Around 400 commits are made daily to the repository, which doesn’t seem like a lot until you compare it to core trac commits. Now WordPress Core never commits until they’re sure the version in trunk is functional (since many of us use trunk on live sites), something most devs don’t have to worry about unless they use trunk as ‘live’… Let’s not talk about that.
Instead of going into code today, I’m going to explain a little theory and talk about what version control is, why you want to use it, and how to use it.
If you’ve ever saved a document, had MS Word crash, and come back to be asked what version of the document you want to restore, then you actually already have an idea of what version control is. You’ve possibly just never had to do it yourself. Version control is a very simple concept: saving versions of a file so you can go back to the older ones. Sounds easy right? Yes and no. Most people are accustomed to a different way of saving.
Traditionally, we’re taught about saving as something you do regularly and often. After all, we’ve all lost that crucial document by forgetting to save. Apple has been changing this on us, having a much more robust auto-save process, and a better restore. It coaxes you into a place where you don’t think about saving anymore. There’s no save button on my iPad, and I actually use it to write a lot of the time. That freaks me out still, but so far it’s worked really well.
In contrast, I have my coding. I sit and write, save a lot, test a lot, and when I’ve got a change that works, I commit my code. You see, version control is like a second type of saving. One save is me working, and one save is me ready for someone else to test. But the best thing about version control is how it saves changes. You check in code, and SVN (or Git), and the server checks the changes and records what changed in a way that is easy to read. Here’s an example picked at random from the hundreds I skimmed today:
KatePhiz’s checkin of changed code
See how beautiful that is? Right away you can see what changed between versions! You, and anyone else who wants to troll a revision log, can see what you changed, which makes it easier for people to write a change log for you (if you happen to work that way).
Where I see the most people making mistakes with version control is missing out on the two rules you need to adhere to, if you want to use them effectively.
Never Delete Files
Trust The Tool
That’s it. That’s all you have to do. I see a lot of people correct files by deleting them and uploading new versions. This is flat out doing it wrong, but I can see why people think it’s what they should do. You have to trust your tool, and know that it will see the new file, tell the differences and record that. If you delete a file, it stops you from being able to compare it to earlier versions and that’s a problem. Bug tracking becomes much harder, as you no longer have a quick and easy way to see what changed. Sure you can compare two files, but you’ve now put up a barrier for the next guy who picks up your code. What if she doesn’t have that previous version? What if she has no way to get to it, and you were hit by a bus and are in a coma? Or not. But still, building barriers between yourself and the next person is lacking foresight. Worse, you build barriers for yourself.
It’s hard to trust the tool, and just as it took me months to get used to the iPad’s way of saving files, you have to get used to how version control saves things. This isn’t FTP where you’re always replacing a whole file, you’re making incremental changes. A check in is not a delete and replace (unless you’re using some of the horrific tools I’ve had the dubious pleasure of using in the past). Getting past that one hurdle will make your life much better with any tool you use.
As for never deleting, I come to this from working at a bank. We never deleted anything. Ever. Not once. You always keep all versions of your code, even the broken stuff, because legally you had to. But in the end, I feel that was a great practice to get into. Disk space is cheap and you won’t ‘run out’ of space any time soon. I keep a copy of every plugin’s latest version on my hard drive, and I’m not out of space.(I don’t have SVN checkouts, that would be a little much.) Also there’s no point to deleting your older code, since they’ll just show up in SVN anyway. It remembers everything you checked in. Ever.
Now, I cannot give you advice on the best way to tag or branch code, as each person comes up with their own methodology. I will say this: Don’t use ‘trunk’ as your stable releases on SVN. Git’s a little different, but I wouldn’t use it there either. Instead, use trunk as your playground. When you have a functional change, commit that minor change. When you have a major change and it’s ready to go, tag it and release it. In that way, your beta testers can safely use trunk, and your normal users never get hurt. By the way, making frequent commits may feel like a smart move, but you don’t need to. Check in a working copy. Oh and don’t go back and edit your tagged versions, unless it’s a very minor change. Someone is sure to have downloaded it, just tag a new version and go forward. As I always explained to people at the bank “You don’t go backwards with code, you go forward.”
I don’t expect this to be a perfect primer on how to use version control, nor was it meant to be, but I hope I demystified it a little. If you have great primers for people on SVN or GIT, aimed at first time users, please share them!
Caveat: You need root access on your Mac to do this!
Ages and ages ago, when I first was using MAMP and all that fun stuff, Apple didn’t include a version of SVN. I had installed, and promptly forgotten about, my 1.4.4 install sitting out there. Now, I know I upgraded it to 1.6.something at some point, but I only found out that was wiped out when I went to svn up some code on my site and it all died. My version of SVN was too old.
svn --version was coming back as 1.4.4 and I knew that was wrong. I complained on Twitter, and Eric Hitter pointed out that Xcode has SVN (and Git) so I went and installed that. It didn’t work, I was still stuck on 1.4.4.
After checking that, indeed, svn was located at /Applications/Xcode.app/Contents/Developer/usr/bin/svn, and that ran the right version, I deleted 1.4.4 manually by removing the following folders:
Then I made a fast alias ln -s /Applications/Xcode.app/Contents/Developer/usr/bin/svn svn over in /usr/local/bin/ to redirect my scripts, and finally I followed the directions from Panic to fix Coda, and changed the Subversion tool path setting in the Files pane of Coda’s Preferences to /Applications/Xcode.app/Contents/Developer/usr/bin/svn. I also changed git to /Applications/Xcode.app/Contents/Developer/usr/bin/git and made a fast link for that too, since I can.
I’ve been putting off learning git. I’m lazy, svn works fine what what I need, and … oh. Look. MediaWiki switched to git. This is a problem for me, because I upgrade my MediaWiki install via svn. When it comes time for a new version, I just run something like svn sw http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_18_1/phase3/ ~/www/wiki/ and I’m off to the races. But now I have to git off my ass and learn it.
Before someone asks, I use svn to update my code because I like it better than wget-ting files, unzipping, and copying over. I can certainly do that, but I prefer svn. It runs fast, it lets me see what changed, and it’s easy for me to back out, just by switching back to the previous version. It never touches my personal files, and I’m happy. The more I looked at git, and how it works, I started to wonder if this was a practical idea for upkeep anymore.
Now, I actually like git for development when you’re working with a team. It’s great. So any posts about how I’m stupid for wanting to do this weird thing will just be deleted. Constructive or GTFO. The rest of this post details the journey of going from ‘This is what I do in svn, how do I replace it with git?’ The tl;dr of it is that I can’t.
What I want to do
I want to check out a specific branch (or tag) of code and upload it to a folder called ~/www/wiki/
That’s it.
The road…
First up, I have to install git on my server. Unlike SVN, which has been bog-standard on servers for a hog’s age, git is the new kid in town, and the odds are it’s not on your server. Thankfully, my host had note perfect directions on installing git on CentOS 5.(I’ll probably upgrade to CentOS 6 this summer, when my sites are less busy.)
Second I have to ‘install’ the git repository. This was weird. See, I’m used to svn, where you check out code, use ‘svn up’ to upgrade it, or ‘svn sw URL’ to switch to a new branch/tag. The official directions for gitting MediaWiki were: git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git
That doesn’t tell me what version I’m getting, and I only want the latest stable release. It was unclear at this point what this cloning did, but I was told over an over that I had to clone to get the version I wanted. Thankfully, git knows a lot of us are in the WTF world, and have a nice crash course for SVN users. Most important to me was this:
So git clone URL is svn co URL and that’s how I first installed MediaWiki. But… I know MediaWiki is working on a million versions and I’m not specifying one here. The git doc goes on to say that for git, you don’t need to know the version, you use the URL and it’ll pull the version named ‘master’ or ‘default.’ That basically means I’m checking out ‘trunk,’ to use an svn term. This is exactly what I do not want. I have no need for trunk, I want this special version.
After more reading I found git checkout --track -b branch origin/branch which they say is the same as svn switch url which is excellent. I can also use git checkout branch to check out the specific version I want!
I’m very used to SVN, where I can browse and poke around to see the tags, branches, and so on. When I go to https://gerrit.wikimedia.org however, all I see are the latest revisions. The directions said I should get the file /r/p/mediawiki/core.git which makes me presume that’s what tells git the version I’m checking out, but I can’t see that. I don’t like obfuscation when I’m checking out code. After some digging, I found the URL I wanted was https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git and that shows me the files, and their tags.
The tags were important for the command I wanted to run: git checkout tags/NAME where NAME is the tag. I want version 1.18.2, which is the latest stable, so I want to do is git clone -b tags/1.18.2 https://gerrit.wikimedia.org/r/p/mediawiki/core.git
I tried it with pulling a copy of 1.18.1, and it ended up pulling about 89 megs and put it in a subfolder called ‘core’. Oh and it told me it couldn’t fine tags/1.18.2 and used ‘HEAD’ instead, which put me on bleeding edge. It took a while to find something that looked a little better:
In theory, that would get me the latest and greatest of release 1.18, be that 1.18.1 or 1.18.2 and then, when 1.19 was released, I could switch over to that by doing this: git checkout REL1_19
It was time to test it! I pulled REL1_17 and … ran out of memory. Twice. fatal: Out of memory? mmap failed: Cannot allocate memory happened right after resolving deltas. Everyone said ‘You need more swap memory’ but when I looked, it was fine (not even using half). So that was when I said ‘screw it, I’ll go back to tarballs.’
Just as I hit that wall, some Twitter peeps stepped in to explain that, no matter what, I have to clone the whole archive first. I’m not really happy about it. I like SVN, since even when I switch, it’ll only update my changed files. I wanted to be able to do that in git without needing to pull down the whole repo, since I only use it to update, and not develop.
And that there is my one and only issue with git. It’s entirely for developers. Sometimes, some of us just want to pull down the latest version to play with, and not the bleeding edge. With git, I have to clone the repository, then export the version I want to play with. That’s not optimal for what I want to do. On the other hand, I totally get why it’s done that way. It’s akin to the basic svn check out, where I get all the branches and tags, only much much cleaner. And that’s cool! Smaller and leaner is fantastic.
And yet I’m not a developer in this instance. I don’t need, or want, the whole release, just a specific stable release. So now my workflow would be…
Install
On Git:(Of note, every time I try to run checkout I get “fatal: Out of memory, malloc failed (tried to allocate 1426604 bytes)” and I get the same thing when I try to archive. If I use the tool to change memory allocation, it also fails … out of memory. I’m taking this as a sign.)
Now, someone wanted to know why I like this. Pretend you’re trying to test the install. You often need to test a specific install version, say version 1.17.1, against some code to see how far back something was broken. Being able to quickly pull that, without coding any extra steps, is crucial to fast testing and deploying. The tool we use at my office required me to reverse engineer and script a way to do that with an ant script, and certainly I could script all that here. It’s not even that hard. But what’s one line in svn is three in git, on it’s best day, and you’re always pulling the latest and reverting back to the one you want, which seems a little silly.
Now, someone pointed out I could use this: git checkout-index -a --prefix=/home/user/public_html/wiki/ When I read the man page, it doesn’t say you can pick a tag/branch to push, though. If you have some advice on how to fix that, I’ll give it a shot, but I suspect my memory issues will block me.
I will be using git for a lot of things, but a fast way to update, spawn versions, and test will not be one. For development, however, I totally adore it.
We use cookies to personalize content and ads, to provide social media features, and to analyze our traffic. We also share information about your use of our site with our social media, advertising, and analytics partners.