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.
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
Sure, things could have been done better. But it’s easier said than done. Modern technology is very complex. And it changes fast. And businesses want to move fast too. And the proper resources (time, money, people) are not always allocated for mission critical tasks. One thing is for sure, the responsibility lies on a whole bunch of people for a whole bunch of decisions. But the hardest job is right now upon the tech people to bring back whatever they can. There’s no sleep. Probably no food. No fun. And a tremendous pressure all around.
I wish the guys and gals at GitLab a super good luck. Hopefully they will find a snapshot to restore from and this whole thing will calm down and sort itself out. Stay strong!
And I guess I’ll be doing test restores all night today, making sure that all my things are covered…
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:
“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.