Gitg has much the same feel as gitk does, but feels much more polished and is well worth a look. I find it quite handy to view the history of projects to get a visual representation as to what has happened in the history. It also has the ability to stage and commit changes.

Definitely check it out if this sounds like something you would find useful and you are using the gnome desktop environment.

There certainly are some good things to be said for it. It has an impressive feature set, and an intuitive interface which allows the store admins flexible control over discounts, pricing, taxes, etc. However there are some strong drawbacks to consider before taking the plunge and integrating it on a site.

First off, it is fairly resource hungry. If you are in a shared hosting environment, I would not consider it a viable option at all. Page load times will be significant, and adding an item to a cart will require the patience of Job. On a dedicated environment there are a number of tweaks that can be implemented to bring this down to a much more acceptable level however.

Secondly, nail down your requirements for the store first. If Magento doesn’t do what you need out of the box, or there aren’t any modules available in the community that meet your needs, anticipate a steep learning curve. Magento is developed using the EAV data structure, so don’t expect to be doing many direct SQL queries yourself to access data. Also, the object API is poorly documented, and in some cases broken.

Templating can be a bit of a bear until you learn which files to edit. Even then, a single page may be split across about a dozen files. Be sure to enable the theme developer hints in the configuration. This will help you out immensely in tracking down where content is coming from.

Lastly, I would recommend checking out the magento forums. There are so many threads that start with “Has anyone gotten magento to do x?” followed up with “I would like to know as well… anyone?”. The development team doesn’t seem to be able to keep up with the requests for features and isn’t the most communicative.

However, if you have your own server (or a good level of control over the environment and resources the project is being deployed in), and only need the features that are available through the interface, it can be a great solution to put in place.

Has anyone else had experience in Magento they wish to share? I’ve been told I should start a support group.

Doing a bit of researching, I found that using git it is possible to commit some of your changes instead of all of them. To do this I have found the interactive commit command the most straight forward to use.

To begin an interactive commit,  issue the command with the –interactive flag (note, that’s two dashes, not the one long one)

git commit --interactive
           staged     unstaged path
  1:    unchanged        +3/-0 index.php
 
*** Commands ***
  1: [s]tatus	  2: [u]pdate	  3: [r]evert	  4: [a]dd untracked
  5: [p]atch	  6: [d]iff	  7: [q]uit	  8: [h]elp
What now

As you can see it gives you a number of options. In this case we want to patch the file so we hit ‘5′ and then hit enter.

What now 5
           staged     unstaged path
  1:    unchanged        +3/-0 [i]ndex.php
Patch update

This is showing us a list of files that we can choose to patch from. Hitting 1 will select index.php for patching. You have to hit return again to begin the process after a file has been selected.

Patch update 1
           staged     unstaged path
* 1:    unchanged        +3/-0 [i]ndex.php
Patch update
diff --git a/index.php b/index.php
index 90ea18f..e2f84ef 100644
--- a/index.php
+++ b/index.php
@@ -1,7 +1,10 @@
 this is a test of how to commit partial files
+this is the first addition to the file
 some more changes
+and another line goes here
 testing
 and some more testing here... this is fun!
 
 adding some content to the bottom of the file
+okay, last one for now
 and a couple more
 
Stage this hunk [y/n/a/d/s/?]?

Hitting ’s’ will split the current hunk and show you the changes to the file one hunk at a time giving you the option to stage the change or not.

After you are satisfied with how you have things set up, hit 7 to quit when given the option and git will bring you to the familiar comment adding screen.

Doing a git diff right after doing this will show you that only the staged changes got committed, the rest are still waiting there for whenever you’re ready to commit them as well.

It turns out this is being caused by a pre-commit hook. There are two options you can go with to circumvent the issue.

git commit --no-verify .

The –no-verify will bypass the pre-commit hooks. This only works on the current commit thought, so you have to add the flag each time you want to commit.

I’ve found that if you

cd .git/hooks/
chmod -x pre-commit

will disable the pre-commit hooks permanently by removing the executable rights on the file.

Apparently they are disabled by default in newer releases.

Hope this helps someone else out as well.

One thing that I have found while working with git is that there isn’t a wide selection of graphical tools to interact with the repository. There is gitk which comes with a default install of git. This program gives you a visual representation of the workflow of the repository that you’re currently working on. From your checkout folder typing gitk should bring up a window similar to this one.

You’ll see a list of commits and a line tieing it to the parent commit. If you have a team of developers working on a single project, this can make for some interesting graphs to say the least. Tags are highlighted with a nice yellow flag which makes them stand out. Right clicking on a commit will let you view the differences between it and the currently select commit. Also, you can roll back the master branch to the selected version. In the bottom right pane there is a list of changed files on the currently select commit. Right clicking on one of these will let you bring it up in an external diff tool to view the changes that were made (I recommend meld for this).

If you were looking closely at the previous screen shot, you may have noticed that this was a clone of the Giggle repository. It’s also an sudo apt-get install giggle for simplicity’s sake. Giggle has a nicer interface that fits in with the gnome desktop environment better as you can see from the screen shot.

Also, built in to the giggle interface is the ability to commit directly from there which seems to be lacking from the gitk app unless I’m completely missing something.

The last app I’ll look at for today is qgit4. This program is one that I cloned and compiled locally. You can make a clone of the repo by typing in

git clone git://git.kernel.org/pub/scm/qgit/qgit4.git

Then cd qgit4 and type in

qmake qgit.pro
make
make install

You’ll need the Qt developer libraries installed for this to work, but if all went according to plan, you should have a bin directory with a qgit4 executable in it now. It should looks something kinda like this:

Qgit4 seems to be one of the more full-featured programs I’ve come across yet. It feels like it fits in more with the KDE desktop environment withsince it uses the Qt libraries. However, it lets you create multiple tabs if you want to take a closer look at each file and what changed. Clicking on a revision will show you the list of files that changed in the bottom right pane as well. Then right clicking on a file can open it in an external diff viewer as well.

I think each of these programs has their place. For quick ‘what change in this commit’ gitk seems to fit the bill nicely (albeit rather ugly) and if you’re using gnome, I recommend giggle (if you can bring yourself to using a program named giggle… just don’t tell anyone else).

For typical day-to-day operations like committing, adding files to version control, and tagging I find that using the command line is pretty hard to beat though. However, having tools like these available will make git accessable to a wider audience, and easier to pitch to the team for your next development project.

What IETester will do, is install Internet Explorer 5.5, 6, 7, and 8 beta 2 on your computer all in one nice interface without messing up your current browser settings. It also uses the correct javascript engines in addition to the rendering engine for each version, so you are able to experience your site just like your poor visitors who are using IE.

The only downside I have found, is that this is a Window XP / Vista only application. I spent a couple minutes with Wine trying to get it to run with limited success. If anyone figures that out, please leave a comment and let me know, as I would love to have this running on Ubuntu 8.10, but for time being I’ll use my wife’s laptop which has Windows on it.

The interface is based off of the ribbon design that MS Office 2007 introduced and incorporates tabs where you can have different versions of IE all open to the same url. A handy feature I noticed is the ‘refresh all tabs, no cache’ which does exactly what it says. Typically, I’ll open the page I want to test in the 4 different version and then keep using the above mentioned button to load up the changes in all the tabs at once. All in all, I highly recommend grabbing this tool. It’s bound to save you many hours of frustrating work.

Typically (in Subversion and CVS for example) you will have a central server which all the developers check their code in to. For a project not too long ago I was required to learn git, a distributed version control system. There were a number of reasons for doing so, but the most important (well, in my opinion) are:

• off-line repository access – we can work on our code changes and check in, even if we don’t have internet access.
• local repository – I can make as many check-in’s and changes as I like without interrupting or checking in potential conflicts with other people’s code. Also, I feel more free to check-in experimental code without the concern it will disrupt anyone else.

There are a few distributed version control systems (D-VCS’s) that are currently being actively developed and used. Bazaar, Mercurial (hg), and Git seem to be the most prominent at the time of writing with Git and Bazaar both gaining steam. Personally, I have chosen to migrate my personal projects over to git from svn due to my familiarity with the system now.

Quick start:

this will create an empty directory and initialize a git database

mkdir test
cd test
git init

now, create a text file and add some text

vi hello.txt
hi, I am file version 1.0

next we need to tell git to track this file and any changes that happen to it

git add hello.txt

at this point we can check the status of the repository by issuing a

git status

and you should see something like

# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#    new file: hello.txt
#

This tells you that you’re currently on the master branch (more on branches in another post) and that this will be the first commit to the repository. The next few lines will list the files that have either been added, changed, or removed since the last commit.

Now you can issue a

git commit .

to commit everything in the current working directory. Git will ask you for a comment to let other deveopers (or yourself if you’re forgetful like myself) know what changed since the last commit.

Now you can keep making changes, adding / removing files and committing as often as you would like. Running the comment

git log

will output a list of all the changes that have been made

Prior to committing a file, it is sometimes handy to compare the current file with the previous one. This is accomplished with

git diff hello.txt

The real power of git comes into play when you clone someone else’s working repository. To try this out, go to www.github.com and find a random project and click on the clone URL and copy and paste the command (ie: git clone git://github.com/rails/rails.git to clone the ruby on rails source code). This will pull down not just the latest copy, but all the history and changes that have been made to the project to your local machine. You can now make your changes, and if you have permission do a

git push .

to push your changes back to the server you downloaded them from (hence the term distributed).

If there is interest, in the future I will do a series on tagging and branching and how to use them to keep an organized, stable set of code, while making major changes in a safe manor as well as some graphical tools which can make your life easier while trying to merge changes / fix conflicts.

It turns out, this was because of the way IE handles the onchange javascript event. This only fires once the checkbox loses focus. To fix this, I just switched from the onchange event to the onclick event and everything works as expected. I’ll retract some (okay, just one) of my nasty comments about Internet Explorer now as this does make logical sense thinking about it now.

So the offending code looked like

<input type="checkbox" name="mycheckbox" value="something" onchange="update_div();">click me

whereas it should be:

<input type="checkbox" name="mycheckbox" value="something" onclick="update_div();">click me