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.
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.
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!
Like this:
Like Loading...
RSS - Posts