Tag: git

Go Monorepo

As a maintainer and contributor to multiple, and often related, git repositories, I often find myself thinking that there must be a simpler way.

Consider, for example, a variety of CakePHP plugins that we develop and maintain at work.  Sure, each one provides a completely separate bit of functionality and has its purpose as a standalone project.  But, at the same time, they all have enough overlap that we use a common cakephp-plugin-template repository to keep things in sync, and also require cakephp-utils plugin from all of them.

It’s only natural to consider other ways of doing things.  Sure, I tried git submodules before, but they don’t quite cut it.  Something is still missing.

Today I came across the Go Monorepo website.  Which makes me wonder even further down this road.  There are also a few other tools and alternatives mentioned in this article.

That’s not something that I’ll jump into right now, but it’s definitely something I’ll consider to try out in the nearest future.

Highlights from Git 2.19 and PHP syntax

GitHub blog covers the highlights from Git 2.19, which was recently released.

One particular change that I want to highlight (which GitHub skipped in their highlights, but which exists in the Git release notes for this version) is the syntax pattern update for the PHP files.

Let’s have a look at the full diff of this release.  The particular change I am referring to is in the userdiff.c file.   Git now understands final, abstract, interface, and trait keywords.

If you are not sure where and how it is used, here are a couple of useful links for you:

Now that you have it all configured, there are a couple of ways to benefit from this functionality.  First, you’ll see a more useful context comment in the diffs.  Here’s the screenshot (using an older git version still).  On the left, the diff without the PHP syntax configured, and on the right is the diff with the PHP syntax configured:

As you can see, on the left, the context shows that the change was done somewhere in the ChangeLogTrait trait.  On the right, the context is much more specific – it shows that the change was done in the public function changelog.

This makes reviewing code changes a lot easier.  But there is also one other place where this is useful – in reviewing the history of a particular function.  For example, running “git log -L :changelog:ChangelogTrait.php” will produce the git log output containing only the commits and diffs on the function changelog in the file ChangelogTrait.php.  Very handy!

15 Tips to Enhance your Github Flow

“15 Tips to Enhance your Github Flow” has lots and lots of good advice for anyone working with GitHub.  Tips vary from PR templates all the way to automated dependency management and updates.  Really useful!

git worktree – a better way for git stash abusers

If you constantly find yourself using “git stash” while working on a project, or, even worse – have multiple copies of the same project cloned on the same machine, “git worktree” might be a much better alternative for you.

Manage multiple working trees attached to the same repository.

A git repository can support multiple working trees, allowing you to check out more than one branch at a time. With git worktree add a new working tree is associated with the repository. This new working tree is called a “linked working tree” as opposed to the “main working tree” prepared by “git init” or “git clone”. A repository has one main working tree (if it’s not a bare repository) and zero or more linked working trees.

When you are done with a linked working tree you can simply delete it.

Here are a few links to get you started:

 

commandlinefu – a place to share and gather command line wisdom

commandlinefu is a place to learn and share your knowledge about command line tools and techniques.  It has thousands of tips, tricks, and handy shortcuts, covering a wide range of tools from shells and editors to version control and remote access.