- The Apprenticeship patterns book is very interesting! I shall continue to read it and start create daily/weekly rituals from the actions prescribed in the book!
- I was reading this post on
reflog, etc. and wanted to see what the default values were for some of the configurable variables. But, the git config command didn't help. Developer/code defaults are also a part of the "config" system, and any tools to inspect config variables should display them, if no other values have been set explicitly!
- "If experience is built upon failure as much as success, then you need a more or less private space where you can seek out failure." – Apprenticeship Patterns.
- Our check-in groups changed, but 3 of us from our last check-in group are together again!
- Most of the day was spent with Git. In the morning, I learned that
nothingwill prevent pushing any branches without specifying explicitly which branch I want to push.
- Also, later in the day, Alan gave a presentation mapping the internals of git to the commands, trying to give everyone a better mental model of Git.
- I spent some time trying to get
emacs. It should've worked out of the box, but I'm not sure the ELPA repositories have proper dependency/version management. Seems to be the problem, everywhere! Dependencies of a package get updated, and the package starts acting up…
- Chaitu sent me a link about solving mazes using Finite Automata, and I spent some time trying to write a simple solver, and compare it with Nava's breadth first search. But, it looks like we broke her code during the refactor. I may get back to this, at some point.
- I also spent a few minutes talking to Kyle, while he was trying to implement a simple version of the NTP protocol. The algorithm it turns out, is pretty simple.
- I started reading a little bit on crypt-analysis for Simple Substitution ciphers, and I'll try implementing one of the algorithms today.
- The day ended with yummy pizza and video watching! We watched –
One of the things with git that you can mess-up, if you are not used to, is git diff. A friend of mine was trying to add a couple of new files, and changes to existing files. But, he was on the wrong branch, and wanted to change to a different branch, before committing. Being new to git, he wanted to take a patch. Reset the changes, apply the patch back.
This is what he did
git add new_file.txt git add old_file1.txt old_file2.txt # don't add old_file3.txt
Oh, damn, I want to change the branch.
git diff > a.patch git reset --hard git checkout other-branch
Let me commit my changes…
git apply a.patch git commit -m git show
Oh crap! Where are my new files? They aren't commited! Lemme add them.
ls new_file.txt ls: cannot access new_file.txt: No such file or directory
Dammit! Where are my changes gone?
The problem was with
git diff. It gives only the only the
--cached option has to specified, to get the
staged changes in the diff output.
git diff HEAD shows diff
output with both staged and un-staged changes.
But the whole workflow above is a beginners workflow. A user comfortable with git would've committed and then moved the commit around using cherry-pick or the like.
git add <all-files> git commit -m "My awesome changes." #committed on branch1 git checkout other-branch git cherry-pick branch1
Over the last two days, I hacked up my first Chrome extension. I've been using Chrome only for the past couple of weeks or so and I begin to like it, though some of the extensions aren't as mature as I would've liked.
The original idea was floated by my friend, Madhu, and Lee helped me quite a bit, while I was working on it.
What does it do?
It is a simple extension, that shows pop-ups, whenever there is an update in your GitHub "Wall" (yes, this is a Facebook world) or News Feed as they call it.
After installation, you will need to save your
token for the extension to work.
Where to get it?
Presently, you will need to get it from GitHub.
I might add it to the Chrome Web Store, once I see more people using it. I couldn't justify, to myself, paying the initial one-time verification fee that Google asks for.
UPDATE:Added GetHub to the store
Comments and Feedback
- Feel free to write to me at
- Or file issues at GitHub.
I accidentally came across the blog-post Git-powered wikis improved - GitHub. And this particular paragraph caught my eye:
The new editor has the capability to support every markup language that GitHub Wikis support. If you're a fan of Markdown, Textile, pod or RDoc, the function bar buttons (e.g. bold, italic, underline, etc.) will now work. We've even written brand new inline help for many of GitHub Wiki's supported markup languages.
The language definitions the editor uses are JSON-based and easy to edit. If you'd like us to support a markup language that we don't currently support, Gollum, GitHub's wiki software, is entirely open source – fork our code and send us a pull request with changes that support your choice language.
I sent a quick patch for org-mode in the function bar, and it has been accepted. :)
If not anything more, I hope, at least a couple of curious people will explore org-mode and find it useful.
At work, we use hg and to be frank, I haven't really got the hang of using it well. I've recently started using git for my own work and I'm loving it.
I chose git because
- github seems to be a nice place to hang around, as compared to bit-bucket.
- org-mode uses git and I need to learn to use git, if I intend
contribute anything to org-mode.
But after using git for a month or so, I'm totally loving using git. The way it handles merges is awesome. People go gaga over it's speed.
But for me, it's the way it handles branches. I can have any number of branches on my machine, while pushing only changes in the master branch, upstream. I can easily merge changes from one branch to another. After putting up a lot of fight, I couldn't make hg do this. Not as well as git does it!
I've now decided to convert my personal repositories to git.
This blog post shows how to.