When I’m working with Git, there are times I want to check if I can do a fast-forward merge but I do NOT want to actually perform the merge.
I was doing some troubleshooting and wanted to disable the “beforeunload” event listeners on a page. This is how I accomplished it with the Chrome browser.
Typically a Git commit has exactly one parent, however a Git merge commit has two parents. The problem this creates with Git revert, is it is unclear which commit we want to revert to.
A Pull Request (PR) should always be up to date with the branch into which it is being merged. Another way of saying this is you should be able to merge your PR as a fast-forward merge (even if you decide not to do a fast-forward merge). In this post we’ll look at how a safe looking PR that is out of date can be catastrophic to merge.
When deleting a large directory from the command line, it can take a frustratingly long time for the task to complete. This is a trick I use to speed things up.
Recently, I was documenting the steps to reproduce a certain bug and the bug required the presence of an autosave (along with the “There is an autosave of this post that is more recent than the version below.” message). Rather than wait for an autosave to occur naturally, I wanted to speed things up and manually trigger one. This is the command I use to do that.
I’ve been using Git for a number of years. When I was a Git beginner, I followed some prescribed steps and things worked – most of the time. This seems to be a pretty common experience for people starting out with Git. The magical part is when I started to understand Git, when I went from beginner to intermediate. These are some blog posts and videos that would have helped me with that transition.
I was recently working on a project that loaded WordPress from a sub-directory. The result of which is if I cloned the project into the “public” directory, the WordPress files and directories were one level deeper (in “public/wordpress”).