Testing GitHub pull requests before merging

My personal projects on GitHub oftentimes. It’s very flattering when other people get interested in your personal work, and actively use it. GitHub pull request is how other people suggest changes to our code.

Pull requests can be merged in GitHub with just one click, but it’s also possible – and recommended – trying the changes locally first. The usual way to do this is creating a local branch, then pulling the modified code onto it.

As an example, let’s take pull request #75 of WinSafe. We create another branch called foo and check the pull request onto it by using:

git fetch origin pull/75/head:foo
git checkout foo

Simple enough, and for some reason it took me years to try this for the first time today.

Adding a branch from another repo in Git

This should be something rather rare, but for some reason I keep needing to do it very often: I want to add a new, unrelated branch into an existing repository, and this branch comes from another repository.

While needing to do this yet again today, I found a rather elegant solution here:

git checkout --orphan NEW_BRANCH
git reset --hard
git pull FORK_URL FORK_BRANCH

It works remarkably well and clean. Props to the guy who shared this.

Fixing Cargo authentication on GitHub

Today, while performing tests before publishing the first version of WinSafe, I stumbled across a problem I had with Go a few weeks ago. It was caused because GitHub no longer accepts user/password authentications, so everything must be done via SSH. I solved the problem by adding some lines to my ~/.gitconfig file.

But Cargo still cannot fetch packages.

After a lot of digging, I found a setting that finally worked. It involved adding another filter to ~/.gitconfig, which now looks like this:

# Force SSH instead of HTTP
# https://stackoverflow.com/a/27501039/6923555
[url "ssh://git@github.com/"]
	insteadOf = https://github.com/
	
# But crates.io needs to pass
# https://github.com/rust-lang/cargo/issues/8172#issuecomment-659066173
[url "https://github.com/rust-lang/crates.io-index"]
	insteadOf = https://github.com/rust-lang/crates.io-index

The “crates.io” directory was updated and I could use an external crate, something that will be needed when I publish my own.

As a side note, all downloaded crates are stored in ~/.cargo/registry/ directory, which can be safely wiped out to clean the cache.

Displaying current Git branch in Bash prompt

I decided to show the current Git branch at my bash prompt whenever I’m at a directory which contains a repository. I found a rather convoluted Bash-esque solution, which I adapted to myself:

gitbranch() {
    git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ \1/'
}
#export PS1="\u@\h \[\e[32m\]\w \[\e[91m\]\$(gitbranch)\[\e[00m\]$ "
export PS1="\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\[\e[33m\]\$(gitbranch)\[\e[00m\]\$ "

It’s compact and it works as intended.

Cleaning up a Git repository

Sometimes, after you mess up too much with your Git repository, it ends up with a couple useless objects, which are no longer referenced anywhere.

I created this alias a while ago, collected from sources I don’t remember anymore, to perform a cleanup in the repository. It’s particularly useful right after a git fetch:

alias gitcleanrepo='git fetch origin --prune && git -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 -c gc.rerereresolved=0 -c gc.rerereunresolved=0 -c gc.pruneExpire=now gc "$@"'

Let Go website generate your documentation

When trying to figure out how go doc command works, I just found out that I don’t need to use it.

There’s an incredible feature of Go documentation website: it can generate and display the documentation of all your project, straight from GitHub – and other websites too. The generated HTML is very polished.

To use it, append your GitHub user name and repo to their URL, such as:

https://godoc.org/github.com/username/reponame

Even more interesting: all types and Go built-in types are automatically linked. And it also provides direct links to GitHub source files. On top of all that, it’s very fast. Written in Go, I suppose.

Being a C language admirer, the more I work with Go, the more I like its simplicity.

The joy of Git Submodules

I’ve been using Git Subtrees for more than two years to manage the dependencies of my projects in Git. Today I found this article explaining Git Submodules, and I realized that I had it all wrong. Submodules suits my needs much better.

I finished migrating my C++ repositories which have WinLamb as a dependency. The nested “winlamb” folder effectively acts as a separated repository, without interfering with the top one. No more annoying merges with a huge hash as the commit message, when updating the library.

Git commit with specific date

Very interesting Git option I just found: --date. When making a commit, you can specify the date manually. However, if you make a new commit with a past date, it will still be shown as the last commit, even with a date prior to the previous commit.

A new commit at January 1, 2019, 12:00, specifying timezone UTC-2:

git commit -m "Comment" --date="2019-01-01T12:00:00-02:00"

Changing the date of the last commit, using UTC+0 as timezone. Will be prompted to write the comment:

git commit --amend --date="2019-01-01T12:00:00Z"

This goes hand-in-hand with this current date trick.

Git amend updating date and time

When commiting code on Git, very often I realize I forgot some little detail right after I end the commit operation. This is very annoying. Fortunately, we have the amend command. Recently I found a very cool trick to use with amend command: updating the date and time of the commit together with amend.

So, with those in hand, I’m now using a nice alias on my ~/.bashrc file:

alias gitamend='git commit --amend --date="$(date -R)"'

And my own memory faults are now easily addressed.

Trying out Git Subtree

Currently I have 5 projects on my computer which use WinLamb library. So far I’ve been keeping copies of the library directory on each project; these directories are kept in sync with FreeFileSync Portable. Although this approach works, it’s very cumbersome.

Since each project is versioned as a Git repository, and WinLamb itself is a Git repository on GitHub, I started searching for an alternative, and I choose Subtree over Submodule. Following is a summary of the commands I needed to do on my Windows 7 x64, using Git portable v2.13.1:

1. Remote

Add a remote with the path to the repository of the shared project:

git remote add otherproj --no-tags git@github.com:username/otherproj.git

Or if a local project:

git remote add otherproj --no-tags d:/stuff/otherproj

You can view the remotes with:

git remote -v

2. Subtree

Run the Subtree command:

git subtree add --prefix otherproj otherproj master --squash

This will copy the library into the subdirectory and create a commit, with the hash in the message. It’s unnecessary, but you can provide a custom message for the subtree commit:

git subtree add --prefix otherproj otherproj master --squash -m "Subtreeing otherproj."

3. Updating

To update your project with new library code:

git subtree pull --prefix otherproj otherproj master --squash

This leads us to a nice bash function to our ~/.bashrc file:

function gitsubtreepull { git subtree pull --prefix $1 $1 master --squash; }

Which eases our life when updating our Subtree library:

gitsubtreepull otherproj

So far this approach seems to the better than the old-fashioned directory sync, although it still feels a bit “loose”. I’m still avoiding pushing code from the local repository to the shared library; if I change something, I just copy the code to there, then I update the library repository itself.

Note: beware amending a commit on the remote library. The next time you try to update the dependency, it’s likely to get lost, and you’ll have to remove the subtree and add it again.

Git .gitignore file to Visual C++ 2015 Update 2

After upgrading my Visual C++ 2015 from Update 1 to Update 2, I noticed that a new file appeared in the root directory of the projects I was opening. The file was always named ProjectName.VC.db. Indeed according to the release notes, a new SQLite-based database engine is now being used by default, and that’s the file where the database is stored. The old file, named ProjectName.sdf is now unused and can be safely deleted.

The change also demanded an update on my .gitignore files to also ignore this new database file, and here it goes:

Debug/
Release/
*.aps
*.db
*.ffs_db
*.ncb
*.opensdf
*.rar
*.sdf
*.suo
*.user
*.VC.opendb
TODO.txt

If you import and old .vssettings file, however, the option to use the new SQLite-based database can be rolled back to the old .sdf files. To manually change it, go to: Tools → Options → Text Editor → C/C++ → Advanced → Browsing/Navigation → Enable New Database Engine. Set it to “true”.

Git bash shortcut on Windows

Download the portable version of Git (it can be x64), and create a shortcut to run Git bash on Windows with this command line to run on “target”:

C:\Windows\SysWOW64\cmd.exe /c ""C:\Program Files (x86)\git\bin\sh.exe" --login -i"

Start in: root directory of sources.

Portable Git on Windows

I use Git on Linux a lot, but these days I was willing to use it on Windows too. I remember some time ago I found some ugly installers, so I thought there should be a portable package. For my surprise, I found one: msysgit. It’s a self-contained package build upon MinGW with everything one would need.

And it’s incredibly easy to use: just unzip the package anywhere, then doubleclick “git-bash.bat”. Like magic, you have a Linux-like terminal with a ready-to-use Git. And all the stuff exhales quality: it seems to be very well built and feels good on the tip of the fingers.

Now if you need to use Git on Windows, there’s no other way to go but msysgit.