Gazler's comments

Gazler | 11 years ago | on: Show HN: GitCop – Automated Commit Message Validation for GitHub Pull Requests

It is common in many flows to expect people to do a force push if something is wrong with their pull request, e.g. having 15 commits that look like:

    Try stuff
    Another prototype
    Fix something
    ...
    Revert prototype
It is fairly common (in my experience) for the contributor to be asked to squash those commits.

In my opinion, the more guards in place the better.

Gazler | 11 years ago | on: Show HN: GitCop – Automated Commit Message Validation for GitHub Pull Requests

Thanks for the ideas.

I think there are several avenues that could be explored with this. I wanted to stay away from explicitly checking the code initially, as there are other tools aimed at that specific task, however there is no reason something like this couldn't be added into GitCop at a later date.

I had the idea of checking that the user exists in a list of users by specifying a JSON list of users. This means that it could be used to check if a CLA has been signed, but there are other applications too. Does this seem like a reasonable way to do it?

I like the idea of ensuring a test has been added, not sure how to tackle it, but it is certainly worth keeping in mind.

Gazler | 11 years ago | on: Show HN: GitCop – Automated Commit Message Validation for GitHub Pull Requests

Glad it made sense!

So the match is exact between the non %{..} characters. The idea for scope is the context of the commit, in my libraries I use the name of the class as the scope.

For example with the default format string:

    test string: "fix(User): ensure email address is required"
    format:      "%{type}(%{scope}): %{description}"
    [type: "fix", scope: "User", description: "ensure email address is required"]
So any literal characters are matched exactly and anything inside the capturing %{...} is assigned to that variable.

This does fall over in the following case:

    "fix():(User): ensure email address is required"
    "%{type}(%{scope}): %{description}"
    [type: "fix", scope: "):(User", description: "ensure email address is required"]
It is certainly a candidate for improvement in the future.

Gazler | 11 years ago | on: Show HN: GitCop – Automated Commit Message Validation for GitHub Pull Requests

Hi, thanks for the feedback, it would be great to be used by a project like Foreman!

Currently the string for the format only allows the 3 defined variables, type, scope and description. I have been using this style at https://github.com/Gazler/changex/commits/master to give you an idea of how it works.

I was concerned that the format string might be a little weird to get from the help. I will try and clear this up a bit.

I have attempted to build the string that you requested, currently an or separator is not supported, but I can take a look at adding it in.

Here are the format strings that I think match your use case. Using a colon as a separator:

    test string: "Fixes #1234: foo"
    format:      "%{type} #%{scope}: %{description}"
    [type: "Fixes", scope: "1234", description: "foo"]
Using a hyphen as a separator:

    test string: "Fixes #1234 - foo"
    format:      "%{type} #%{scope} - %{description}"
    [type: "Fixes", scope: "1234", description: "foo"]
I hope this makes sense, let me know if you get it working!

Gazler | 12 years ago | on: Repository Next

Yeah, me too. It happens to me at least daily. I don't think I have ever wanted to search within the repository and it certainly shouldn't be default. In fact, I might write a browser extension to make it global by default again.

I don't mind the navigation being on the right, but the clone url doesn't appear on most repositories which is one of the most important elements of the repo.

Gazler | 13 years ago | on: Drupal benchmarking with NGINX and Apache

Surely you are just benchmarking Varnish and Drupal is irrelevant in the equation? The other results are more useful. Interesting to see how little it takes to kill Apache for a stock Drupal install.

Gazler | 13 years ago | on: Free Book: An Introduction to Programming in Go

I really like the structure of this, very readable and a great intro. I have some confusion on http://www.golang-book.com/6

It says:

Go also provides a shorter syntax for creating arrays:

x := [5]float64{ 98, 93, 77, 82, 83 }

We no longer need to specify the type because Go can figure it out. Sometimes arrays like this can get too long to fit on one line, so Go allows you to break it up like this:

However the type is specified as `float64`

page 1