Gazler

Not sure when you were using Elixir, but releases are a good option for deployment now. This is supported with the distillery library (https://hexdocs.pm/distillery/home.html).

The master version of Elixir also has support for releases https://hexdocs.pm/mix/master/Mix.Tasks.Release.html

There are a few. This page lists the IETF QUIC implementations and gQUIC implementations (which is supported here) at the bottom. https://github.com/quicwg/base-drafts/wiki/Implementations

I wrote something a few years ago that does a similar thing using a real command line. https://github.com/Gazler/githug

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.

I think doing it like that is a neat idea. Perhaps there could be an "advanced" page which is as you describe and the current method could be the "simple" version?

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.

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.

This is a great idea, definitely something worth implementing. Thanks for the feedback.

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!

Thanks for the feedback, I hope your dev team find it as valuable as you do.

I'm not too familiar with Atlassian Stash, I will have a search around and see how plausible it would be to integrate.

A git hook would certainly work for this as you described and I would certainly encourage people to investigate that route if it is appropriate for them. http://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

The goal for GitCop is to be fast and easy to set up in a way that integrates well into a GitHub pull request based flow.

Thanks for the feedback, I am a fan of the pricing schema too!

An example of the messages GitCop outputs can be seen at https://github.com/Gazler/gitcop-test/pull/2 if you are interested.

Excuse the self promotion I wrote a tool aimed at teaching git at https://github.com/Gazler/githug

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.

Perhaps these examples weren't the best. When searching for more general things it helps to put in golang. For example "Running go on multiple machines" or "Running go on multiple cores":

https://www.google.co.uk/search?q=running+go+on+multiple+mac...

vs

https://www.google.co.uk/search?q=running+golang+on+multiple...

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.

My goto ruby solution looks something like:

(1..100).map{|i|(f=[["Fizz"][i%3],["Buzz"][i%5]].join).empty? ? i:f}

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`

The hash (#) character isn't working for me (UK layout keyboard, Firefox 10 on Ubuntu).

Define expert, I'll see what I can do!

I agree, if you are showcasing code, it should be easy to view. Ideally without even having to download anything by letting people view it on Github.

Does the PSD work well in the GIMP? Or are there the usual layering and font issues?