Manage git hooks easily in your composer configuration. This package makes it easy to implement a consistent project-wide usage of git hooks. Specifying hooks in the composer file makes them available for every member of the project team. This provides a consistent environment and behavior for everyone which is great.
Any git repository contains a tonne of information about commits, contributors, and files. Extracting this information is not always trivial, mostly because of a gadzillion options to a gadzillion git commands – I don’t think there is a single person alive who knows them all. Probably not even Linus Torvalds himself.
git-quick-stats is a tool that simplifies access to some of that information and makes reports and statistics quick and easy to extract. It also works across UNIX-like operating systems, Mac OS X, and Windows.
There is probably a gadzillion different ways that you can manage and synchronize you configuration files (aka dotfiles) between different Linux/UNIX boxes – anything from custom symlink scripts, all the way to configuration management tools like Puppet and Ansible. Here are a few options to look at if you are not doing it already.
Personally, I’m using Ansible and I’m quite happy with it, as it allows me to have multiple playbooks (base configuration, desktop configuration, development setup, etc), and do more things than just manage my configuration files (install packages and tools that I often need, setup correct permissions, and more).
Recently, I came across this tutorial from Digital Ocean on how to manage your configuration files with git. Again, there are a few options discussed in there, as even with git, there’s more than one way to do it (TMTOWTDI).
The one that I’ve heard about a long time ago, but completely forgot, and which I think is quite elegant is the approach of separating the working directory from the git repository:
Now, we do things a bit differently. We will start by specifying a different working directory using the core.worktree git configuration option:
git config core.worktree "../../"
What this does is establish the working directory relative to the path of the .git directory. The first ../refers to the ~/configs directory, and the second one points us one step beyond that to our home directory.
Basically, we’ve told git “keep the repository here, but the files you are managing are two levels above the repo”.
I guess, if you stick purely to git, you can offload some of the additional processing, such as permission changes and package installation, into one of the git hooks. Something like post-checkout or post-merge.
Terminals are sexy is a curated list of Terminal frameworks, plugins & resources for CLI lovers. There is plenty of links to applications, plugins and configurations. For me personally, the most useful one was the link to sensible Bash configuration.
I’ve searched for this before, and I’m sure I’ll do that again (although the need is not that frequent), so here it goes. It is possible to move files from one git repository to another, preserving commit history. The following links provide a few examples of how to do this:
With that, running “git mergetool” after a conflict was reported, will result in something like this:
The three way split window will show local version (–ours) on the left, the remote version (–theirs) on the right, and the base version with the conflict in the middle. You can then get changes from one window into another using the following Vim diffget commands:
:diffg RE " get from REMOTE
:diffg BA " get from BASE
:diffg LO " get from LOCAL
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.
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.
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: