Want to do your part for software engineering research? Participate in the annual University of Victoria developer practices survey and help us to build a picture of how developers create software in 2013.
Want to do your part for software engineering research? Participate in the annual University of Victoria developer practices survey and help us to build a picture of how developers create software in 2013.
Problem
Solution
Benefits
Risks
This article describes how to include the GitHub Wiki as a submodule in a GitHub project (or any git repo for that matter).
Lets say we have a GitHub repo called “project” and we want to include the associated Wiki as submodule in a dir called “docs”. We want the following dir structure:
- parent
- docs
This section deals with setting up a submodule for the first time.
Get the address of your Wiki repo, it will be something like this:
https://github.com/username/project.wiki.git
Add the Wiki repo as a submodule “docs” to a dir within the “project” local copy:
$ git submodule add https://github.com/username/project.wiki.git docs
Commit the addition of the docs submodule to the parent repo:
$ git commit -m 'first commit with submodule docs'
Push the change to the remote server:
$ git push
Lets look at whats in “docs”
$ cd docs
If you look in the docs dir you’ll notice that its currently empty. You have to initialize the submodule and update it separately. Do the following:
$ cd..
$ git submodule init
$ git submodule update
The submodule is now setup and the docs dir should now have the Wiki docs in it.
One you have the submodule setup you can pretty much forget about it. However, if someone pushes changes to the parent repo that includes changes to the submodule you can pull them down as normal.
$git pull
This will pull down a new commit pointer for the submodule but it wont update the files in the submodule. Instead you need to merge the new submodule commit pointer (basically overwriting the existing submodule commit pointer)
$git merge origin/master
Now that the submodule pointer is pointing at the correct submodule commit you can do your submodule update
$ git submodule update
This will pull down the changes to the submodule up to the commit that came down in the parent pull
I know it seems like a lot but its actually pretty simple if you think about it, normally you will just use the following commands to pull and merge changes to the submodule:
$git pull
$git merge origin/"branch"
$git submodule update
If you want to make changes directly in the docs submodule for example manually editing the Wiki files or pulling down changes to the Wiki repo made by other developers. Its just like working with any repo except you do two commits, one in the submodule and one in the parent:
$ cd docs
Notice that docs is at a particular commit not on a branch, if you make changes you probably want to checkout the master or another branch.
$ git checkout master
Make your changes and commit as normal (note you are now committing to the submodule repo)
$ git commit -am "changed wiki files"
Now push to the remote, it is really really important that you remember to push submodule commits to the remote (see Gotcha 2).
$ git push
Now got back to the partent project and do another commit, that basically says I have updated the submodule which is in you, here is a pointer to the new version of the submodule
$ cd..
$ git commit -am "updated docs submodule"
Push the changes to the remote
$ git push
If you are cloning a project that contains an existing submodule, all you need to do after cloning the repo as normal is to initialize the submodule:
$ git submodule init
$ git submodule update
I live in Outlook, I know its terribly unfashionable in the age of thin clients and the cloud but I just can’t give it up, for what I need it just works. I recently wrote this small tool to help me export rules that I define in outlook so that I can import them into Gmail as filters and have then run on the server rather than on the client. You can grab the code from GitHub by clicking here (Code) or download it below.
UPDATE – 9/7/2013
– Version 0.0.2 is current stable version
– 1500+ downloads on GitHub – Thank you.
– Added support for some new rule types see GitHub
DOWNLOAD
0.0.2 – supports more rule types (Stable version)
0.0.1 – only supports from move-to-folder rules
USAGE
– See instructions here http://bcleary.github.com/outlook-gmail-rules-export/
Using Git and LaTeX can be fun to get up and running, but its even more fun if you want to use an editor like TeXnicCenter.
The main problem in using TeXnicCenter and attempting to collaborate with others over git is what to do with TeXnicCenter project and Latex build files. By default these files will be put in the directory where your tex files are which will cause problems when you go to push your changes. You can add all the files to .gitignore but that is a bit of a pain. Instead create a sub directory (lets call it “projectFiles”) and copy all the build files into it. Then in TeXnicCenter open Build -> “Define Output Profiles” and add the following to the latex compile command line arguments “-aux-directory=projectFiles” Now when you compile Latex all the build files will be put in this directory.
If you are using projects in TeXnicCenter then you will have one further .tcp file in the root directory. This is the project settings file. You can manually move this to the “projectFiles” directory also but make sure to update the path to the MainFile to reference the parent directory. For example “../Main_file.tex”.
Also to get BixTeX to build you will have to specify where you moved the .aux file so open Build -> “Define Output Profiles” and add the following to the BibTex command line arguments “projectFilesPath\%tm” replacing projectFilesPath with the full path to the project files folder. Note if you have other arguments already in there you might to overwrite.
Now that we have all the build and project files organized we can simply add an entry to .gitignore to instruct it to ignore the “projectFiles” directory.
Get updates changes from Git
git fetch origin
git merge origin/master
Push you changes
git commit -am 'comment'
git push origin master
Normal service is resumed, which means I’ll probably be back here in a year or so đ
This is an update to my previous post about disabling script debugging in VS 2008. To disable script debugging in VS 2010 add the following registry key using the command prompt (note your just updating the VS version number);
reg add HKLM\SOFTWARE\Microsoft\VisualStudio\10.0\AD7Metrics\Engine\{F200A7E7-DEA5-11D0-B854-00A0244A1DE2} /v ProgramProvider /d {4FF9DEF4-8922-4D02-9379-3FFA64D1D639} /f
see http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/19f91aa2-fb1b-40e9-bfb3-e2ee4fcfe7b8/
When installing IIS onto vista or windows 7 in âTurn Windows features on or offâ dialogue you might for example click on the root tree âInternet Information Servciesâ to indicate your wish to install all sub components and features, however clicking on the root of the tree is not enough as you actually have to drill down to find the web development sub tree open that and then select the leaf nodes for ASP.net (and ASP if you need it).
Really non intuitive tree control, i understand that it is giving me a recommended configuration rather than installing everything which very few users will need, but i think the design of the control is not obvious.
In Visual Studio (2005, 2008 & 2010), if you have multiple web projects in a solution a separate instance of the development web server âCassiniâ is launched for each web project when debugging. If you are only debugging a single web project all these instances are probably unnecessary. Setting a single startup project in the solution properties menu does not solve this issue, instead you have to explicitly stop each web project from launching a server instance. This is done through the properties grid in the properties window (View -> Properties Window) for the web project not through the Properties menu (right click on web project -> properties) (someone please give me a good reason why there are 2 properties menus).
In the properties grid for the project you want to exclude, simply change the âAlways Start When Debuggingâ property to False. This prevents a server instance being created for that web project, rinse and repeat for other projects you donât care about.
A really annoying issue that can arise in VS 2008 if your attempting to debug a site with a lot of javascript (which comes for free with the AJAX toolkit is you get a new node in the solution explorer detailing each little piece of javascript that is loaded just in case you need to debug it. This is great and all but it looks like nobody tested this with a production size site because anything more than a small amount of JS and it slows to a crawl.
There does not appear to be a solution in VS 2008 for this, you are basically back to hacking the registry to disable script debugging.
Open a command prompt and type;
reg add HKLM\SOFTWARE\Microsoft\VisualStudio\9.0\AD7Metrics\Engine\{F200A7E7-DEA5-11D0-B854-00A0244A1DE2} /v ProgramProvider /d {4FF9DEF4-8922-4D02-9379-3FFA64D1D639} /f
See here for more;
http://blogs.msdn.com/greggm/archive/2009/04/06/disabling-script-debugging-in-vs-2008-ie8.aspx
http://pagebrooks.com/archive/2008/04/23/easily-disable-javascript-debugging-in-visual-studio-2008.aspx