GIT Merge conflict solving with kdiff3

First we will create a test repository and a test file on which we will create a merge conflict later on.
(in this example, the commands are executed with PowerShell in Windows, but the GIT commands are exactly the same on any other shell or OS)

• Creation of test repository
  

  > cd \tempmd mergetestcd mergetest
  > git init

• Creation of test file
  

  > 'Original line' | Out-File file.txt
  

• Commit into repository
  

  > git add file.txt
  > git commit -m "Original checkin"

• Current repository state: (using the tool GIT Extensions)
  

Now we will create a new branch A, and update the file.

• Create new branch
  

  > git branch branch-A
  > git checkout branch-A

• Update file
  

  > 'Branch A line' | Out-File file.txt

• Commit into repository
  

  > git add file.txt
  > git commit -m "Branch A change"

• Current repository state:
  

Now we will create a new branch B, and update the file with a conflicting change.

• Create new branch, starting from the original master branch
  

  > git checkout master
  > git branch branch-B
  > git checkout branch-B

• Update file
  

  > 'Branch B line' | Out-File file.txt

• Commit into repository
  

  > git add file.txt
  > git commit -m "Branch B change"

• Current repository state:
  

All this was a preparation for what we will do now: merge the conflicting change of branch-B into branch-A.

• Select the target branch (in this case branch A)
  

  > git checkout branch-A

• Merge the source branch (in this case branch B)
  

  > git merge branch-B

• This results in a merge conflict:
  

  Auto-merging file.txt
  CONFLICT (content): Merge conflict in file.txt
  Automatic merge failed; fix conflicts and then commit the result.

• This conflict can be resolved by starting your mergetool
  

  > git mergetool

• It gives you a message before it launches your mergetool (in my case kdiff3):
  

  Merging:
  file.txt
  
  Normal merge conflict for 'file.txt':
    {local}: modified file
    {remote}: modified file
  Hit return to start merge resolution tool (kdiff3):

• You get a window containing 4 versions of the same file:
• Top left: "Base".  This is the original version of the file, the last shared version between what became later branch-A and branch-B.
• Top Middle: "Local". This is the target branch version of the file.  It is called "Local", because this is the currently selected branch (using the last git checkout command).
• Top Right: "Remote". This is the source branch version of the file. It is called "Remote", as apposed to "Local".
• Bottom: "Output". This is the merged version of the file. After successful completion of the merge, this will become the new version of the target branch.  In this pane, you can edit the text, or you can right click on any merged part and select what version(s) of the original file you want to include in the output.  In this case, I decide to include the changes done in both branch-A and branch-B.
  
  
• Close the kdiff3 application (saving the file), and commit the merge:

  > git commit
  (accept the default commit message)

• This brings us to the following repository state:
  
• We can check if the content of the test-file is what we need:
  

  > Get-Content file.txt
  Branch A line
  Branch B line
  

   

Python scripts inside PowerShell window

After installing Python on Windows, you can start a Python script by executing the script file-name.
E.g.:
./MyScript.py

However, the command is not executed in the same PowerShell window.  It opens a new command window to start "python.exe", which executes the command (and immediately closes the window).

This behavior can be changed, and the script can be executed within the current PowerShell window.

Just add the ".py" file extension to the PATHEXT environment variable.  This can be done by executing this command:
$env:PATHEXT += ";.py"

You can add this command to your "$profile" file, so you don't need to execute this command in every newly started PowerShell window.  Run the next command to add this line to your $profile automatically:
"`n" + '$env:PATHEXT += ";.py" # Transparent execution of Python scripts' |Out-File $profile -Append -Encoding Default

You can test it by creating and running a small script:

'print("Hello, World!")' | Out-File MyScript.py -Encoding Default

.\MyScript.py

Uploading a file to Amazon Glacier using PowerShell

For my own convenience, I created a PowerShell module to upload backup files to Amazon's new backup service "Glacier".

The module is contained in this file:
http://dl.dropbox.com/u/2350654/blog/FxAWS.zip
(including the Amazon AWS SDK library)
Extract it into your Powershell module directory, e.g.
C:\Users\<your name>\Documents\WindowsPowerShell\Modules.
(this will create a directory FxAWS under the directory Modules)

Start powershell and run:
Import-Module FxAWS

C:\Users\wim devos.GENOFFICE> Write-AWSGlacier -AWSAccessKey '<access key>' -AWSSecretKey '<secret key>' -AWSRegion <some region> -
GlacierVault <vault name> -Filename <filename> -Description <description>

e.g.

Write-AWSGlacier -AWSAccessKey '[your access key]' -AWSSecretKey ' [your secret key] ' -AWSRegion us-east-1 -GlacierVault "backup" -Filename "backup-20120830.7z"


The parameters are:

• AWSAccessKey and AWSSecretKey.
  These are NOT your login and password to log on to the Amazon.com web site.
  You can find the access key and secret key in your Amazon.com account:
  https://portal.aws.amazon.com/gp/aws/securityCredentials
  Extra credentials can be created and they can be removed individually.
• AWSRegion.
  The region where your Glacier Vault has been created.
• GlacierVault
  The name of the Vault that you created in the Glacier administration website.
• FileName
  The file that you want to upload.
• Description (optional)
  A description used in the Glacier administration website.  When none is specified, the last part of the filename path is used.

You can create 3 (global) PowerShell variabled $AWSAccessKey_Default, $AWSSecretKey_Default and $AWSRegion_Default, in which case you can omit the -AWS* parameters.

Cleanup old files from your harddisk using PowerShell

This script removes all files from the current folder (in this case 'c:\temp') that are not accessed during the last 3 months.  A confirmation is asked because -Confirm is included.

Get-ChildItem -Recurse | where { $_.LastAccessTime -lt (Get-Date).AddMonths(-3) } | Remove-Item -Recurse -Force -Confirm

Dell Service Tag using PowerShell

Today I needed to know the "Dell Service Tag" of a machine in another room.  The service tag is always printed on a sticker on the chassis of the machine. Dell also stores the Service Tag in the "SerialNumber" field of the System BIOS. So, when you are too lasy to go look at the machine, you can run this PowerShell command:

(Get-WmiObject -Class Win32_Bios).SerialNumber

Loading .net 4.0 assemblies in PowerShell 2.0

.Net assemblies can be load using the command "Add-Type - Path ./MyDotNetAssembly.dll". The last versions of Visual Studio build .net assemblies for .Net Framework version 4.0.
By default, PowerShell uses the .Net Framework version 2.0 run-time, and then you get the following error message in PowerShell:

Add-Type : Could not load file or assembly 'file:///C:\...\MyDotNetAssembly.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
At line:1 char:13
+     Add-Type <<<<  -Path .\MyDotNetAssembly.dll
    + CategoryInfo          : NotSpecified: (:) [Add-Type], BadImageFormatException
    + FullyQualifiedErrorId : System.BadImageFormatException,Microsoft.PowerShell.Commands.AddTypeCommand


To resolve this problem you can change the config file of PowerShell to let it load the .Net Framework version 4.0 instead of version 2.0.  This can be done using the PowerShell.exe.config file.
Locate the program PowerShell.exe which is normally "C:\windows\System32\WindowsPowerShell\v1.0", and create/update the file PowerShell.exe.config beside it, with this configuration:

<?xml version="1.0"?> 
<configuration> 
    <startup useLegacyV2RuntimeActivationPolicy="true"> 
        <supportedRuntime version="v4.0.30319"/> 
        <supportedRuntime version="v2.0.50727"/> 
    </startup> 
</configuration>


On 64-bit machines, the location of PowerShell is the same, but the 32-bit version of PowerShell is located under "C:\windows\SysWOW64\WindowsPowerShell\v1.0".  When you use the 32-bit version of PowerShell, you should create/change the config file there too.

The same trick can be applied to other software that hosts PowerShell, such as PowerShell_ISE.exe.