{"id":6478,"date":"2019-01-30T10:25:30","date_gmt":"2019-01-30T15:25:30","guid":{"rendered":"https:\/\/jdhitsolutions.com\/blog\/?p=6478"},"modified":"2019-01-31T09:37:07","modified_gmt":"2019-01-31T14:37:07","slug":"powershell-scripting-getting-git-size-retooled","status":"publish","type":"post","link":"https:\/\/jdhitsolutions.com\/blog\/powershell\/6478\/powershell-scripting-getting-git-size-retooled\/","title":{"rendered":"Getting Git Size with PowerShell Retooled"},"content":{"rendered":"

A few days ago I wrote about my experiences in designing a PowerShell function that reports on the size<\/a> of the hidden .git folder. In that version of the function I decided to include a parameter that would permit the user to get the size pre-formatted as either KB, MB or GB. I thought long and hard about it as this really is not the best design pattern.\u00a0 Still, I'm not the only one who likes the ability to get values formatted into a more user-friendly form. So let me show you a revision that I think better adheres to PowerShell scripting best practices, yet also provides the flexibility of data formatting.<\/p>\n

<\/p>\n

Extending a PowerShell Object<\/h2>\n

One of the things I appreciate about PowerShell is how easy it is to extend or modify an object type. This is because PowerShell has an extensible type system. Using the Update-TypeData<\/a> cmdlet, it is very easy to add new properties to an object type. That is the approach I decided to take. I decided to keep my \"base\" object very simple and show the directory size in bytes. This means I removed all the code around the -As parameter.<\/p>\n

#get the total size of all files in the .git folder\n$stat = Get-Childitem -path $git -Recurse -File | Measure-Object -Property length -sum\n\n#create the output\n$obj = [PSCustomObject]@{\n    Path  = $full\n    Files = $stat.count\n    Size  = $stat.sum\n} #customobject\n<\/pre>\n
In order to extend a type you need to know the typename. When creating a PSCustomobject as I'm doing here, this will require a few extra steps to define an additional typename for the custom object. This is typically done with code like this:<\/p>\n
#insert a new typename\n$obj.psobject.typenames.insert(0, \"gitSize\")\n#write object to the pipeline\n$obj\n<\/pre>\n
\n
Update<\/h3>\n
Thanks to a comment from Chris Warwick, there is an even better way to insert a type name that was introduced in PowerShell at some point and I missed it. Define a property called PSTypeName in the object itself.<\/p>\n
$obj = [PSCustomObject]@{\n    PSTypeName = \"gitSize\"\n    Path       = $full\n    Files      = $stat.count\n    Size       = $stat.sum\n} #customobject\n<\/pre>\n
It won't show in the object's output but it will be used for the typename. You can verify it by piping the object to Get-Member.<\/p><\/blockquote>\n
I could also have created a PowerShell class which would have baked in the typename from the beginning. But that is a bit more complicated than I what to get into here. Now for the fun stuff.<\/p>\n
Exploiting Update-TypeData<\/h2>\n
My function will now write an object to the pipeline with a typename of gitSize. I decided that all of the other properties I might want to see were completely optional. To accomplish this I am going to use the Update-TypeData command\u00a0 outside of the function. Since I would need to dot source the script file with the function anyway, I added these lines after the function definition.<\/p>\n
Update-TypeData -TypeName gitSize -MemberType ScriptProperty -MemberName SizeKB -Value {$this.size \/ 1kb} -force\nUpdate-TypeData -TypeName gitSize -MemberType ScriptProperty -MemberName SizeMB -Value {$this.size \/ 1mb} -force\nUpdate-TypeData -TypeName gitSize -MemberType ScriptProperty -MemberName SizeGB -Value {$this.size \/ 1gb} -force\nUpdate-TypeData -TypeName gitSize -MemberType NoteProperty -MemberName Computername -Value $env:COMPUTERNAME -force\nUpdate-TypeData -TypeName gitSize -MemberType ScriptProperty -MemberName Date -Value {Get-Date} -force\nUpdate-TypeData -TypeName gitSize -MemberType ScriptProperty -MemberName Name -Value {Split-Path -path $this.path -leaf} -force\n<\/pre>\n
I also added a few other properties I had been thinking about like Computername and Date. Yes, I could have defined many of these as part of the custom object in which case I would have used code like this:<\/p>\n
$obj = [PSCustomObject]@{\n    Path  = $full\n    Files = $stat.count\n    Size  = $stat.sum\n    SizeKB = $stat.sum\/1kb\n    Computername = $env:computername\n} #customobject\n<\/pre>\n
Regardless, I knew that by default I only wanted to see the path, number of files and size in bytes.\u00a0 As things currently stand, when I run my function I'll get an object that displays everything. The solution is to use Update-TypeData and define a default set of properties.<\/p>\n
#set default properties\nUpdate-TypeData -TypeName gitSize -DefaultDisplayPropertySet \"Path\", \"Files\", \"Size\" -Force\n<\/pre>\n
When I run the function, which will write a gitSize object to the pipeline, I'll get the defaults.<\/p>\n
\"Revised<\/a><\/p>\n
But all of the properties are there if I want them.<\/p>\n
\"Viewing<\/a><\/p>\n
The Extended Function<\/h2>\n
I've left the original function up on Github. This version can be found here<\/a>.<\/p>\n