composer-patches – Simple patches plugin for Composer

composer-patches is a plugin for Composer which helps with applying patches to the installed dependencies.  It supports patches from URLs, local files, and from other dependencies.

I think this is absolutely brilliant!

It’s quite often that one finds bugs and issues in external dependencies.  Once the bug (or even the pull request with the fix) is submitted to the vendor, it can take anywhere from a few hours to a few weeks to be resolved and a new version to be released.

If you have a fix for the problem and need it in your project right away, and can’t wait until the vendor releases the new version, your best choice is to fork the dependency, fix the problem, and use your repository instead of the vendor’s package.  This works, but it’s messy.

With the patches plugin to composer, you can still use the vendor’s package and just apply a patch with composer, until the new version is available.  Clean and simple.

This also helps with testing things and working with different changes by different people, if you want to try things out – no need to choose between multiple repositories.  Just select the patches that you want and apply them at the environment you need.

Given that most development work is happening on GitHub these days, this composer plugin is even more useful than what I might think at first.  You see, GitHub provides patch and diff URL for each commit – all you need to do is add the extension to the URL.  For example, take this recent commit to my dotfiles repository.

Commit screen

If you add a “.patch” extension to this URL, you’ll get a patch output, which is useful for git am, and other commands (more on using git with email):

Patch screen

 

If you add a “.diff” extension to this URL, you’ll get a unified diff output, which you can either apply with diff and patch utils, or use with the composer-patches plugin.

Unified diff screen

So, this gives you a way of applying any commit on GitHub (and other repositories) via composer to any of your dependencies.  This is mind blowing!

 

BitBucket : tag from source

BitBucket has implemented one of the most frequently requested features, which was outstanding for more than three years now – creating tags from the source browser (as in BitBucket web interface, rather than from the local repository, using git and then pushing it to remote).

I didn’t see the announcement in the BitBucket Blog, so I thought I’d post it here.

In order to create a new tag, navigate to the Commits page of your repository, then click on the hash of the commit that you want to tag, and then create the new tag from the upper right corner interface as per this screenshot:

It’s not the most obvious place to have this functionality, and the other feature – the equivalent of the GitHub releases – is still missing, but it’s better than having to use the local repository.

Update (January 23, 2017): BitBucket Blog carries the post now.

git: history of a source code line

git is one of those tools that no matter how much you know about it, there is an infinite supply of new things to learn.  Here’s a handy bit I’ve discovered recently, thanks to this StackOverflow comment:

Since Git 1.8.4, git log has -L to view the evolution of a range of lines.

[…]

And you want to know the history of what is now line 155.

Then, use git log. Here, -L 155,155:git-web–browse.sh means “trace the evolution of lines 155 to 155 in the file named git-web–browse.sh“.

Absolutely brilliant!  I used to suffer through this via an iteration of git blame and git show to the point of custom bash scripts.

Git Workflow Basics

git workflow

Git Workflow Basics” is yet another take on the git workflow.   This subject has been covered in a variety of ways before (here, here, and here, for example), but I think it’s super important for every developer to understand, so if all the other attempts left you puzzled and confused, have a look at this one.  It’s pretty straight forward.

One thing in particular that I would like to emphasize:

And hey: remember to review your own pull request before asking for reviews of your teammates. You’ll spot a lot of small things you didn’t notice (style issues, typos, etc) and will allow your colleagues to focus on what really matters.

Pull Request focused dashboards for BitBucket

PR-focused-dashboard

A few days ago BitBucket announced the re-worked dashboards, which are now much more focused on the Pull Requests that you’ve created or need to review, rather than lists of repositories that you have access to.  I’ve enabled the feature for my team and it looks super awesome!

If you’ve been suffering from being lost in dozens or hundreds of projects and missing out on the Pull Requests activity, check them out.  You’d be surprised.

Git from the inside out

git

Git from the inside out – must be the best thing I’ve ever seen on how git works.  Everybody knows that git is awesome.  Most know that git is implemented with graphs.  But not many know how exactly git stores the project history and how it is affected by different git commands.

And if you are feeling adventurous, there is this:

After reading, if you wish to go even deeper into Git, you can look at the heavily annotated source code of my implementation of Git in JavaScript.

Which, among other things, includes  “Git in six hundred words“.

diff-so-fancy – the best-lookin’ diffs

Here is a cool tool to spice up your regular boring looking diffs – diff-so-fancy.  Don’t get spooked by the npm installation instructions – the meat of it is all in perl/shell and you can install it as any other ~/bin/ script.  Have a look at what you are missing:

diff-so-fancy

Git 2.9

Git 2.9 has been released a few days, bringing in some very useful functionality, such as showing renamed files in git diff and git log, forbidding the merge of two branches that have no common ancestors, configurable path to hooks, and more.  All are welcome changes, making the life of a developer easier.

But what I found interesting is how two largest git companies – GitHub and BitBucket – reflect on it.  Surely, the new release is important to both, but it’s insightful to see which features each of them looks at first.  Have a look:

 

Useful git commands (and GitHub integration)

Garrett Holmstrom’s blog /dev/zero has a nice collection of useful git commands, especially for those people who work a lot with GitHub.  Here are a few links to get you started:

Very handy stuff!

Git rebase and the golden rule explained

Git rebase and the golden rule explained” – is an excellent explanation of what happens when you do rebase in git repository.  If you know already, or don’t care, at least remember the golden rule:

Never, NEVER, NEVER, rebase a shared branch. By shared branch I mean a branch that exists on the distant repository and that other people on your team could pull.