Since starting my Outreachy internship with Mozilla a few weeks ago, my biggest struggle has definitely been version control. I’ve used git before, and I’ve used it to collaborate with others on projects — but I often had issues with branching.
Contributing to the Mozilla code-base was my first experience with Mercurial. Throughout the application process for this internship, I was able to manage working on different bugs (and with each bug, its respective commit) simultaneously. However, in that case, all of the bugs were quite unrelated.
Now, I’m working on a task that involves 5 bugs (and their respective commits) that are very intertwined. I created a commit for each bug, but the real confusion started when I began amending commits to implement feedback from my mentor. Each time I amended a commit, it seemed to diverge more and more from its parent, but I didn’t know how to fix it (or how to even check what my commit tree looked like).
I talked to my mentors about the issues I was having, and it was nice to hear that they too still had issues with Mercurial at times. They also offered to organize a session for an overview of someone else’s workflow (thanks Nihanth!).
That session was really helpful for me. It was great to see someone else’s workflow — and to learn some new commands that would hopefully help to A) resolve my current Mercurial woes, and B) create my own workflow that would prevent the aforementioned Mercurial woes in the future.
So without further ado, here are the commands that have saved my life:
WIP = work in progress. This command allowed me the tree of my commits (it was a MESS, as I had suspected).
This command allows you to browse a repository (and its changesets, log, graph, tags, bookmarks, etc.), on your web browser at `localhost://8000`. (Thank you to Carolina for sharing this command!)
I had used this command before, when working on bugs during the application process, but with my mess of commits, I was scared of losing (and/or breaking) something. After seeing this command (and its options) used in action, I was more comfortable with it. `hg rebase -s EARLIEST_COMMIT_ID -d central` was what really got me started with fixing up my tangled web of commits. This moved allowed me to rebase my first commit onto central, then each subsequent commit onto its parent.
While I’m no longer stuck on Mercurial issues, I still encounter new struggles with version control regularly. For example, due to some issues with my built-in merge tool, I had to solve the merge conflicts manually (it took longer than I’d like to admit to even figure out that there was an issue with the merge tool not properly saving the changes). I also had some more issues due to differing line endings — the easiest (but definitely not best) solution I found to solve this was deleting the contents of the file and re-adding it after rebasing the commit. (If anyone has any advice in dealing with FileMerge/“line endings differ” issues, please send it my way).
Cleaning up my commit history was easier said than done — even with these commands, it still took me a few long, frustrating hours to get clean up my tree of commits. I am elated to say that my rat’s nest of commits has now been untangled— the next challenge is to keep it (at least in some semblance of) that way.
UPDATE — Since writing this post, I have solved my issues with FileMerge (thank you AGAIN to Nihanth). My blame on the merge tool itself was entirely misplaced! It had, in fact, been saving my changes, but I did not realize that it was necessary to quit the program after saving (rather, I had simply been closing it). No more
hg resolve -m path/to/file for me!