List of free programming books

Sounds too good to be true.. via hacker news

Check out this list

Advertisements

Awesome site for learning git

via Johansen Sidabutar: http://think-like-a-git.net/

How to delete a git submodule

I am confused to why the git submodule command is not symmetrical. The command supports adding a submodule, but it doesn’t have a delete submodule command. Why? The argument for “preventing deleting changes” in the stack overflow post is not very convincing. Nevertheless, I found it useful to know how to delete a submodule, so I am just pasting John Douthat / philfreo’s answer here:

———————————————————————–

To remove a submodule you need to:

  1. Delete the relevant line from the .gitmodules file.
  2. Delete the relevant section from .git/config.
  3. Run git rm --cached path_to_submodule (no trailing slash).
  4. Commit and delete the now untracked submodule files.

How to undo a git push

I issued a github pull request for a non-profit / charity project I was working on. I have already forked his git repo, and I pushed my changes to my fork in github. After looking at how other contributors issue their pull requests (request to merge a branch to jorgej’s master branch), I realised that I issued a pull-request from my master branch. It was actually a bit awkward to develop and make changes on my master branch, it makes it difficult to merge updates from jorgej’s upstream remote master branch.

So what I wanted to do was:

  1. close my initial pull request
  2. create a branch starting from jorgej’s latest commit (e.g. fix_branch)
  3. cherry-pick my commit to that branch
  4. issue a pull request to merge from my ‘fix_branch’ to jorgej’s master branch
  5. reset my master branch (on my github fork) to jorgej’s latest commit
  6. also needed to reset my master branch in my local machine, i.e.: git reset --hard HEAD^
step 1 – 4 was pretty trivial, but I’m not sure how to reset my master branch to a previous state. (Since I have already pushed this commit)
Googling — found this really helpful post. Essentially I can force a git push to point to a certain head. Awesome! I thought this was pretty useful, so I’m just going to paste Charles Bailey’s response here:
——————————————————————————–

You need to make sure that no other users of this repository are fetching the incorrect changes or trying to build on top of the commits that you want removed because you are about to rewind history.Then you need to ‘force’ push the old reference.

git push -f origin cc4b63bebb6:alpha-0.3.0 

You may have receive.denyNonFastForwards set on the remote repository. If this is the case, then you will get an error which includes the phrase [remote rejected].

In this scenario, you will have to delete and recreate the branch.

 
git push origin :alpha-0.3.0 
git push origin cc4b63bebb6:refs/heads/alpha-0.3.0

If this doesn’t work – perhaps because you have receive.denyDeletes set, then you have to have direct access to the repository. In the remote repository, you then have to do something like the following plumbing command.

git update-ref refs/heads/alpha-0.3.0 cc4b63bebb6 83c9191dea8

Good code ?

I stumbled upon one of the many coding guidelines at Hacker News this morning. What struck me was that most of them are just common sense.

In summary:
Make it readable

The rest of the article went on to explain “what” is readable and “how” to make it readable.
So, “what” is readable ?
  • Nice layout
  • Clear
  • Short
  • Not ambiguous
  • No surprises
  • etc
“how” to make code readable? Again, common sense (in no particular order):
  • Reduce clutter (comment as necessary, use single-letter variable names when in context)
  • Logical white-spacing
  • Use plain English and make sure it made sense (class and instances as nouns, functions as verbs)
  • Be consistent
The coding guidelines article is still worth a read. There are even books written on the whole topic: Clean Code and Code Complete comes to mind. But reading such article depressed me. Aren’t all this just common sense? Quite often the practice of writing code is treated as distinct and separate from communicating code. This is not true. They are one and the same. IMHO as long as you write code with the courtesy and discipline to make sure other people can understand it, then it will be good code. Not great code…. but you’ll be on the right track.