Today’s post by Phil Haack mentioned using powershell over git bash. Up until now I thought I had to use git bash to communicate with github and use git. I like the idea of using powershell. it falls in line with other windows conventions.
So I finally got it all up and running. To start I had to edit my profile script and replaced my explicit path to git set-alias git "c:\Program Files (x86)\Git\bin\git.exe" with a general path to $env:path += ";" + (Get-Item "Env:ProgramFiles(x86)").Value + "\Git\bin". This allows access to all the executables in the git directory!
Next I installed PsGet. Which is dead simple. After that I cloned posh-git to my user folder and ran .\install.ps1. This updates my powershell profile with a link to some ps scripts by Keith.
I finally fell like I have a command friendly command line perfect for development.
Showing posts with label version control. Show all posts
Showing posts with label version control. Show all posts
Tuesday, December 20, 2011
Thursday, December 8, 2011
“Gitting” up and running… slowly
For my first real project using github I decided to fork Rhino.Etl, my favorite ETL library, and try to update it a bit. To start I wanted to target 4.0. Then I wanted to replace Boo references with the DLR. I don’t use Boo scripts and wanted to remove my dependency on this assembly. I may clean up with code a bit too. There seems to be a lot of noise, but that could just be features I don’t use. Finally I still want to keep Rhino.Dsl in the mix because it is an existing feature of Rhino.Etl.
On top of all this I am learning Git and xunit and psake and … well, there is plenty to learn. So after two evenings of battling with the command line I finally have
To get to this point I first forked hibernatingrhinos/rhino-etl. I saw this hasn’t been touched in a while. I then issued a pull request from Nathan Palmer. His fork was using a newer version of psake. That caused some conflicts which I then resolved via notepad++ (ouch!).
Then came the task of targeting the 4.0 framework. Step one: change the target framework of each project. Step two: build from VS. That was a quick win. Now the build script.
For reasons I don’t understand msbuild was pointing to v3.5. It didn’t know what 4.0 was and kept reverting to 3.5. I tried setting the $framework_version, but it kept reverting. Finally I used brute force to resolve this and used the absolute path to v4.0 msbuild. Another step closer.
Then came xunit. I needed to use xunit.console.clr4.exe to target the 4.0 framework. Otherwise the build would fail stating the framework was built using an earlier version.
On top of all this I am learning Git and xunit and psake and … well, there is plenty to learn. So after two evenings of battling with the command line I finally have
- Rhino.Etl targeting 4.0
- The build script running
To get to this point I first forked hibernatingrhinos/rhino-etl. I saw this hasn’t been touched in a while. I then issued a pull request from Nathan Palmer. His fork was using a newer version of psake. That caused some conflicts which I then resolved via notepad++ (ouch!).
Then came the task of targeting the 4.0 framework. Step one: change the target framework of each project. Step two: build from VS. That was a quick win. Now the build script.
For reasons I don’t understand msbuild was pointing to v3.5. It didn’t know what 4.0 was and kept reverting to 3.5. I tried setting the $framework_version, but it kept reverting. Finally I used brute force to resolve this and used the absolute path to v4.0 msbuild. Another step closer.
Then came xunit. I needed to use xunit.console.clr4.exe to target the 4.0 framework. Otherwise the build would fail stating the framework was built using an earlier version.
Friday, December 2, 2011
Continuing my introduction to GIT
Last I left off I had a simple remote and local repository. Tonight I had a few minutes and decided to tackle local branching and merging. The first difference I found between SVN and GIT is that with GIT I am constantly “checking out”. With SVN you branch and switch. With GIT checkout and switch are the same thing.
Another difference I found was local merging is different as well. with SVN you merge and commit. with GIT you simply merge and the changes are committed automatically.
Another difference I found was local merging is different as well. with SVN you merge and commit. with GIT you simply merge and the changes are committed automatically.
Wednesday, November 30, 2011
My first attempt with GIT
Tonight I decided to get started with GIT. I’m comfortable with SVN and I have read enough about GIT to at least understand the concept of how it works. What I wasn’t ready for was the command line. I’m spoiled by VisualSVN and it mouse click happy UI.
But, I’m pleased to say, that after some reading and few minutes debugging my configs I was able to push my first commit to github. Nothing exciting, just a simple README file.
What I did notice was the lighting fast speed in which the commit was pushed. Everything I read said GIT is faster, but man that was amazing!
I could repost all the commands I used, but that would be repetitive with so many other “getting started” guides out there. Where I made a mistake was defining the local and remote repositories. locally the repository was stored in myfirstgitrepo while the remote was named My-First-Repo. When adding the remote location I first named it myfirstgitrepo. Which was incorrect, that’s the local directory.
To resolve this I had to remove the existing remote connection with git remote rm origin. Then I could add the connection using My-First-Repo. Then a simple git push origin master. Ta-Da! Simple yes, but first steps are usually small.
But, I’m pleased to say, that after some reading and few minutes debugging my configs I was able to push my first commit to github. Nothing exciting, just a simple README file.
What I did notice was the lighting fast speed in which the commit was pushed. Everything I read said GIT is faster, but man that was amazing!
I could repost all the commands I used, but that would be repetitive with so many other “getting started” guides out there. Where I made a mistake was defining the local and remote repositories. locally the repository was stored in myfirstgitrepo while the remote was named My-First-Repo. When adding the remote location I first named it myfirstgitrepo. Which was incorrect, that’s the local directory.
To resolve this I had to remove the existing remote connection with git remote rm origin. Then I could add the connection using My-First-Repo. Then a simple git push origin master. Ta-Da! Simple yes, but first steps are usually small.
Subscribe to:
Posts (Atom)