I finally got tired of manually typing out all of the characters in the branch names that JIRA was creating for my projects on the M1 Macbook Pro that work has provided for me.
Solution is really simple and I’m kicking myself for not having done it earlier now.
Inside a Zshell terminal, type the following two lines:
echo 'autoload -Uz compinit && compinit' >> ~/.zshrc
source ~/.zshrc
That will enable tab autocomplete and reload the shell so the change takes effect immediately.
This weekend, I made an interesting (re)discovery. I was digging though some old emails and found an email with details about how an acquaintance and I were creating a centralized git workflow.
I figured out how to keep my project in sync with yours.
I use git on the command-line, but I imagine it should translate to a GUI tool pretty easily
git add remote upstream
git fetch upstream
git stash //I had uncommitted changes that I had to get off the stack first
git rebase upstream/master
git stash apply //to reapply my changes, I had to manual merge a few issues.Anyway, thought I’d share with you in case you get other contributors to your IDE.
Later,
Ben
This was highly relevant for me personally, as we have been discussing the benefits of SVN vs Git at work lately. SVN’s centralized structure is simple enough to understand that everyone groks it from the jump. But keeping Git in sync, with its distributed workflows, is a much more convoluted process for new users.
With the above setup to a git instance, it allows a user to maintain local changes, while still being able to keep up-to-date with the latest pushed changes. Being able to rebase, based on the most recent changes to the upstream repo (aka, the centralized shared home of the project) makes keeping everyone in a centralized git workflow so much easier.
If you add ‘–‘ to your git command, git will know not to process anything after the double hyphen as a command-line argument.
This was useful to know for the situation I just found myself in. I had accidentally cloned a repo into a directory called “–force”. I had placed the –force argument in the wrong sequence in the clone command. But when I went to remove it from git, I found I could not. Every ‘git rm --force‘ command was throwing up the usage guide for the rm command; git thought I was passing in ‘–force’ as an argument. I found out about using the ‘–‘ argument with git and ‘git rm -- --force‘ got rid of my bad directory.
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!
I am not sure how long Github has offered their Pages service, but I only recently discovered it. And, as I have been trying to improve my workflow, I found the idea of deploying my site with a simple “git push” very enticing.
I experimented briefly with Pages and decided to go with Github for my webpage hosting. However, I quickly realized I had a problem. I had an existing Github repo that housed the code for bencarson.net. I also had a Github repo in ben-carson.github.io that I had created for my Pages experimentation. I didn’t want to lose the history of my original website project. And I also didn’t really want to just copy-and-paste my original site’s files over my Pages repo, that just felt too inelegant. What I really wanted was to combine these two distinct git projects and their histories into one project.
My Git-fu is still pretty weak, so I took to the web for help. My initial searches provided results on merging subtrees and modules and whatnot. More along the lines of keeping a library that a project uses up-to-date, rather than a one-time project meld. Way overkill for my needs. Then I found this post. It was close to exactly what I was looking for.
For the sake of clarity, I’ll include just the (DOS) commands I ran for this process:
C:\> mkdir bencarson-website
C:\> cd bencarson-website
C:\bencarson-website> git init
Initialized empty Git repository in c:/dev/workspace/blog-post/.git/
C:\bencarson-website> dir > deleteme.txt
C:\bencarson-website> git add .
C:\bencarson-website> git commit -m “Initial commit”
C:\bencarson-website> git remote add bc-gh-io-remote https://ben-carson@github.com/ben-carson/ben-carson.github.io.git
C:\bencarson-website> get fetch bc-gh-io-remote
warning: no common commits
remote: Counting objects: 73, done.
remote: Compressing objects: 100% (55/55), done.
remote: Total 73 (delta 11), reused 69 (delta 10)
Unpacking objects: 100% (73/73), done.
From https://github.com/ben-carson/ben-carson.github.io
* [new branch] master -> bc-gh-io-remote/master
C:\bencarson-website> git merge bc-gh-io-remote/master
C:\bencarson-website> git rm deleteme.txt
rm ‘deleteme.txt’
C:\bencarson-website> git commit -m “removing garbage file”
[master 05b4839] removing garbage file
1 file changed, 10 deletions(-)
delete mode 100644 deleteme.txt
#combine the ‘remote add’ and ‘fetch’ commands with the ‘-f’ parameter
C:\bencarson-website> git remote add -f bc-net-remote https://ben-carson@github.com/ben-carson/bencarson.net.git
Updating bc-net-remote
From https://github.com/ben-carson/bencarson.net
* [new branch] master -> bc-net-remote/master
C:\bencarson-website> git merge bc-net-remote/master
C:\bencarson-website> git remote remove bc-net-remote
C:\bencarson-website> git remote rename bc-gh-io-remote origin
C:\bencarson-website> git push origin master
After this, my new, history-merged, site was pushed up to ben-carson.github.io and is available[Edit 03.10.15: removed all my github stuff]! Super easy, once you know how to do it.
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.
I’ve been using command-line git for about a year now. I recently decided to tackle my problem of not knowing how to delete remote branches.
I’ve pushed quite a few branches to some remote repos as a means of transporting projects to/from home/work. As a result there are quite a few useless branches in most of my git projects and it makes working with
git branch -a
more cumbersome than it need be.
In searching for an answer, I actually found out that it is much simpler than I had anticipated. Very similar to what I was already doing to push the branch to the remote repo.
git push origin :<branchname>
That’s it! I just have to add a colon to the remote branch name and git deletes it. Not at all intuitive, but very easy to remember.
Somehow, I broke my Fedora installation this weekend.
After having a great time getting started on my Gravatar project this past Saturday, I settled in for some Labor Day programming yesterday. However, as soon as I tried to open Eclipse, I was given an error message telling me that the command ‘java’ was not in the PATH variable (or something like that)
I have no idea what the hell happened between Saturday and Monday, my laptop was shutdown between those times.
At first, I thought it might be some leftover quirks from the time that Fedora shut itself down when my battery died (the fact that it didn’t warn me is pretty crappy). I ran some fsck’ing on a few mounts. But I don’t know what I’m doing there, so I wasn’t surprised when that didn’t work.
I decided to go for the obvious and just fix the PATH variable. This required me to figure out where this damn variable is in Linux. I also wanted to uninstall Oracle’s JDK 7 as I thought that might have been a part of the problem. First, linuxquestions.org helped me uninstall all java packages with the ‘yum upgrade -y’. I don’t know what it does, but it set me back to using openjdk7. Then a stackoverflow post helped immensely by showing me where my PATH variable was and how to alter it.
After I added the openJDK filepath to my PATH variable, I logged out and logged back in. ‘java’ at the command line works again and Eclipse opens without a problem.
Issue resolved.
Still climbing the very steep learning curve of being a web application developer and admin.
I have dropped CodeIgniter, in favor of CakePHP. A friend of mine recommended this PHP framework, so I’m going forward with it.
I have completed the first tutorial and have a page that will spit out the user data for my app. That’s it. Still a long way to go. But, with the help of this page, I did manage to centralize my CakePHP core. So now I can just point my apps to this one spot for the base Cake code. This will make upgrading the framework easier. I’m sure I will be testing this feature out shortly as the release of CakePHP 2.2 is imminent.
I have also started using bitbucket as my Git repository of choice. Unlimited private repositories that are free?! Yes, please! No more of the public hosting that Github offers. Not that my hosting of my website would be on anyone’s radar, malicious user or otherwise. But it just makes me feel better until I know what I’m doing.
And speaking of malicious users, it seems my blogs have an audience now. I’ve gotten several moderation requests across this blog and comic for spam comment posts. Still no actual comments yet.
I started a new job this week.
It is with a startup company here in Greenville, SC called Green Cloud Technologies. I am super-excited to be here and away from that crap company Windstream! I’ve had a few changes in my career growth as a result of this job change. First, they didn’t have any equipment for me when I started so I am currently using my own PC to work on. This is the same PC that I was teaching myself Linux on. However, I couldn’t very well learn and do everything needed for my job AND learn to do it on Linux at the same time. I’d never get anything done. So I purchased a copy of Windows 7, 8 Gb of DDR2 RAM and brought my PC to work.
That said, my focus on learning has shifted. I am no longer concerned with learning Linux, as all the tech at Green Cloud is new to me. Liferay, Glassfish, Vaadin, Git,…as I said before, I don’t have the mental bandwidth (or equipment now) to learn to use those and Linux. So I guess I’m probably going to start posting stuff on here about my findings with my new technology stack.
I’m currently working on an entry on how I got my Eclipse environment set up with Liferay. If you are using the Liferay IDE plugin with anything other than the Tomcat bundle, you are in for some headaches.
RSS - Posts