Skip navigation

Tag Archives: open source

My first open source contribution was just accepted! (Technically, it’s my 2nd contribution, but 1st accepted one!) It was a very minor change, just an update to the user’s profile page on GitLab. Nevertheless, it’s a great feeling, knowing that I can directly improve a great product that I actually use. And I gained a bit of git experience because of this as well.

simple git history

So pretty!

Before I get to what I broke and how I fixed it, I feel the need to defend my self a little first. I like seeing the pretty, flowy lines that are used to track the commits of a project in git. However, the entirety of my git experience has been as a solo developer. As such, I have noticed that every time I merged my feature branch into master, there was no fork reflected in the history (using git log --oneline --decorate --graph). Just a boring-ass straight line. So, purely for aesthetics and not at all efficient or appropriate, I found a way I could get this fork & branch history to show in my logs. I performed my merges with no fast-forwards (git merge --no-ff). This creates an additional commit that mentions the two branches that are merged together, but achieved the effect I was looking for.

So fast-forward (HA!) to today. I followed my usual, ignorant workflow for my submission to the Gitlab project. I forked their repo, cloned locally, branched, made changes, merged with no-ff back to master, and pushed back to origin. From here, I made a merge request for my change to the official GitLab Community Edition project. An admin wrote back that I needed to squash my two commit messages into one. Blerg, I should have known that this practice would eventually bite me! I spent the next few hours unsuccessfully trying to figure this out on my own. After responding to the admin the next day, that I was still working on this, he wrote back with a very helpful link.
So, to squash my pointless commit that --no-ff generated, I had to rebase back to the commit before my first commit. I did this, in interactive mode (git rebase -i <hash of commit>). This opens a text editor with the history of commits between the latest commit and the one that was selected for rebase. In my case, saw my commit, and the autogenerated commit. From the text editor that appears, I can then select what happens with each commit.

# Rebase 408a140..5d5af41 onto 408a140
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# These lines can be re-ordered; they are executed from top to bottom.
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
# Note that empty commits are commented out

My case was simple. I chose fixup for the superfluous commit and pick for my commit. After saving these changes, the rebase occurred. Everything is fine now, right?
Nope, my dumbass pushed the change to the remote repo already, so I had to overwrite that master branch with my new master branch. A normal git push wouldn’t do it because my local and remote repos were out of sync. Some kind of fast-forward error. So I just forced my changes to overwrite my remote master branch.

git push --force

Ha ha ha Force Push!

git push --force origin master

This force push added my revised master branch to my remote and let me successfully merge my change into the GitLab source! Awesome! Proof positive that you don’t have to be some sort of programming genius to be able to contribute. I don’t even know Ruby!

Hey everybody, kind of an exciting Friday Fix this week. I just submitted my first pull request to an open source project!

First, a little back story. A short while ago I noticed a discussion on Twitter, that spread to github, regarding the name of a particular javascript testing library named Testacular. I believe that it was meant to be a play on the work ‘spectacular’, but it doesn’t take a huge leap to notice that it is one vowel away from the word ‘testicular’. A very valid argument was made that by naming the library in such a way, the project’s author was potentially alienating women and thus undercutting the project’s adoptability. After a semi-heated debate on the project’s github issue tracker, the name of the tool was changed to ‘Karma’. Fast forward to this week, and I’m checking out AngularJS to see what the buzz is about. In checking out the tutorials page, I see a reference and link to the Testacular framework for testing. Knowing that this information is no longer accurate, I click the “Improve this doc” button, modified the references to Testacular, created a pull request, and submitted! As of the writing of this post, the change isn’t on the site. But it does look like it passed testing and will be merged into master at some point.

It is an odd feeling, the level of accomplishment I experienced for having done something so simple. But I guess that’s the nature of open source. So many individuals providing contributions, both large and small, all striving toward a common goal. Everyone wants to improve the project, and anyone can contribute. And now, in a very tiny way, I have helped make the open source community a little bit better.

%d bloggers like this: