Tuesday, August 21, 2018

git bash - deleted local branches

You can find out which branches have been merged into a branch by running the below:

$ git branch --merged origin/master
* master
  feature/some-branch
  feature/some-other-branch

This will also print out master as part of it, so we can then pipe that into grep to match results without master:

$ git branch --merged origin/master | grep -v master
  feature/some-branch
  feature/some-other-branch

Obviously, you won't want the name master in your branch name, otherwise it'll be excluded too. You can fancier with regex here.

Now we can take this result and pipe it into xargs, to run git branch -d passing the output as arguments

$ git branch --merged origin/master
  | grep -v master
  | xargs -r git branch -d

I'm splitting up the command onto separate lines for readability. The -r will only run the git command if there is output.

I've noticed this doesn't always delete all old branches, but it can help. For example, perhaps you had a branch that was a work in progress, or a spike, with changes that aren't merged - this won't be picked up.

You can do one more trick to detect old branches that have no upstream branch anymore:

$ git branch -vv

This will list branches without an upstream branch with gone. Those can generally be deleted too.

Monday, August 20, 2018

Today I learned - VSTS CLI and jq

Today I learned about the VSTS command line tool from a colleague.

I might actually have heard about it before, but wasn't able to try it out because I was previously using the on-premise TFS and not the cloud based VSTS, but hey, today I tried it out :)

For example, you can query VSTS for pull requests you've created by doing the following:

$ cd /your-vsts-git-repo
$ vsts login
$ vsts code pr list --creator "James Barrow"

This will return a JSON object containing info about what pull requests you have created.

If you don't really care about the entire structure, you can then use another command line tool I've come across before called jq.

For example, if you only care about the title, status and url of the pull request, you could do the following:

$ vsts code pr list --creator "James Barrow" | jq ".[] | { title, status, url }"

That's a long command, but what it basically does is pipes the JSON result into jq, which parses it by taking each element in the array of the result, and then filtering it to only take the title, status and url properties of each item in the array.

And finally, since we all know the best way to use git is via the command line and git bash, you can then also create a bash alias in your ~/.bashrc file:

alias prs='vsts code pr list --creator "James Barrow" | jq ".[] | {title,status,url}"'

So you can just check for your pull requests now by simply running:

$ prs
{
  "title": "RE #1234 - some pull request",
  "status": "active",
  "url": "https://blah.visualstudio.com/.../pullRequests/2345"
}

Which gives you something like that ;)

Much simpler than having to open up Chrome, go to VSTS, find the right tab for pull requests, etc...

I want to dig more into using jq to pull out info on if the pull requests have had votes as well, so I can just run a command from my command line and see if I need to follow up on a PR or not, but this will have to wait for another day :)

One last note is that use of single and double quotes might be important depending on your shell of choice, so keep that in mind too.

Hope this helped someone.

UPDATE: There is also vsts code pr list -o table which prints a nice format

Thursday, June 28, 2018

AngularJS to Angular, JavaScript to TypeScript, Gulp to webpack to Angular CLI

So I jotted down a whole lot of links for when I was learning webpack, and thought maybe someday I'd write a blog post, but that I probably wouldn't really. That day may come, but that day is not now :P Posting this in case others may want to browse through the links that I found useful when trying to convert an application in AngularJS 1.x with Gulp, using ngupgrade with Angular5 and webpack, onto just one build with the Angular CLI.

https://youtu.be/ivQ7HrnBJe8

https://webpack.academy/p/web-fundamentals

https://what-problem-does-it-solve.com/webpack

https://survivejs.com/webpack/foreword/

https://webpack.js.org/configuration/

https://webpack.js.org/api/

https://webpack.js.org/api/loaders/
https://medium.com/@MarkPieszak/using-pug-or-jade-templates-with-the-angular-cli-9e37334db5bc
ng add ng-cli-pug-loader
https://www.npmjs.com/package/pug-html-loader
https://www.npmjs.com/package/exports-loader
https://github.com/webpack-contrib/copy-webpack-plugin
https://github.com/webpack-contrib/mini-css-extract-plugin
DONT USE > https://github.com/webpack-contrib/extract-text-webpack-plugin
https://github.com/s-panferov/awesome-typescript-loader
v4.0.0-beta.0 Release Notes

https://gist.github.com/sokra/1522d586b8e5c0f5072d7565c2bee693
https://gist.github.com/gricard/e8057f7de1029f9036a990af95c62ba8
https://webpack.js.org/configuration/optimization/#optimization-minimizer
https://webpack.js.org/plugins/uglifyjs-webpack-plugin/

http://dmachat.github.io/angular-webpack-cookbook/
https://github.com/dmachat/angular-webpack-cookbook/wiki/Angular-Template-Cache

https://github.com/frederikprijck/angularjs-webpack-starter
https://egghead.io/courses/angular-and-webpack-for-modular-applications



Wednesday, June 13, 2018

PowerShell Tips

I'll likely update this as I go along


Create a file like you would with touch

echo $null > filename

Wednesday, May 16, 2018

git-run for managing many repositories

Some may make use of a monorepo, for example over there at Google, however for those of us that don't and have to deal with multiple repositories, possibly unrelated ones across various projects, then a great tool to have in your toolbelt is git-run, or just gr.

It can keep track of where your repositories are located, and can also be used to tag the various repositories. You can then run a git command across all of these repositories (or based on a tag).

To set it up:

$ npm install -g git-run
$ git tag discover PATH

One way I have been using that is to create a tag per project, so across a project which may have many repositories, I can see my git status across all of those by executing:

$ gr @project status

It can also run normal shell commands as well

$ gr @project cat package.json


One thing I realised it didn't do in my git bash shell, was run my aliases that I tend to use (e.g. I have a complicated bash alias for a git log command). But luckily someone else has already got an open pull request to fix this (at least for bash), which suited my needs. Yay for open source!

Try it out and let me know what you think :)

Update: I also recently discovered when trying it on a new computer - make sure you don't forget to add tags to the repositories it discovers during gr tag discover, because it won't save its configuration and you'll get an error.

Monday, March 26, 2018

Package manager tips

Initially I was just going to post about how to install npm packages while offline, but in case I ever come back to update this page with more tips or package manages, this post is now titled "Package manager tips".

npm tips

  1. Configure initial values for npm init -y
    • npm config set init.author.name YOUR_NAME
    • npm config set init.author.email YOUR_EMAIL
    • npm config set init.license UNLICENSED
  2. Installing a package offline:
    • versions older than npm 5, use the local-npm package
    • npm install --prefer-offline
  3. Update a package, e.g. Angular CLI
    • npm uninstall -g @angular/cli
    • npm cache verify # if npm < 5, npm cache clean
    • npm install -g @angular/cli@latest
  4. View the versions of a package:
    • npm view webpack version --json
    • npm view webpack versions --json

yarn tips

  1. Configure initial values for yarn init -y
    • yarn config set init-author-name YOUR_NAME
    • yarn config set init-author-email YOUR_EMAIL
    • yarn config set init-license UNLICENSED

Friday, January 19, 2018

CommonAssemblyInfo

I'm writing this post since I posted this on Twitter, and within half an hour, was asked to share my knowledge:


In Visual Studio, there's a little known feature that lets you add files as links to a project. Using this trick, we can also ease maintenance slightly by having a CommonAssemblyInfo.cs file where common attributes across the assemblies in a solution can be applied, but maintained in a single file.

Here is the sample demo application to show the steps one normally goes through. We have an existing command line utility to calculate tax based on an entered amount and tax rate. Quite simple.


In the Properties folder there is an AssemblyInfo.cs file listing the various attributes applied to the assembly.


This isn't always set up as expected, because most people forget to look at this file. One thing that stands out for example is the Company and Copyright information is defaulted sometimes to Microsoft or some other vendor based on the system settings. This may be undesirable, and so we can update these settings.


See some links at the bottom of this page for more info on these attributes.



You can see these are shown in the properties on the executable that is built.

Maybe we go back to look at our application and want to separate out the domain aspects of the console application, perhaps because in future we may want to share that with a web application frontend. The first step one would do is creating a new project and moving the classes around, fixing references, etc.


But you'll notice that most of these attributes are the same. The only two that maybe would be different are actually just the title of the assembly and the Guid it uses. If we rename things someday, we'd have to update at least two files (maybe we rename CommonAssemblyInfoDemo to something more useful, for example).

The first thing I usually do when creating a solution with more than one project, is first creating a file called CommonAssemblyInfo.cs that lives in the same directory as the solution file (CommonAssemblyInfoDemo.sln). This is usually done outside of Visual Studio, and then using Visual Studio to add the existing item to the solution, to make it easier to edit. I also setup solution folders that are numbered to keep things nicely organised.


You'll notice that only the common attributes are left in this file. But we still need to incorporate it into the other projects.

To do this, we also need to add it as an existing item to each project, however, there is a trick - we need to add it as a link.




You'll notice in the Solution Explorer that the icon of the file has a link symbol in it, to indicate it's just a reference to an existing file, so that all links refer to the same file.

Now we just update each projects AssemblyInfo to just include the information related specifically to that project.


If we need to update the AssemblyVersion across the entire solution, it's now a simple matter of just updating the CommonAssemblyInfo file to do this, instead of going through each project and remembering to update each one.

Hope this helped someone, the extra effort when setting up a new project can sometimes save time in the future.

For example, if we had a continuous integration build, and we just wanted to update the version number across all these artifacts based on some number set in our CI system, we could just update the CommonAssemblyInfo file before we run the solution through the build.

Links