Git on Noetic Nought

Elfeed DB backup hooks

Tue, 20 Jan 2026 23:13:00 +0530

I had a bunch of things running on my laptop – video call with screenshare, my Windows VM, Firefox with a lot of tabs, etc. And my laptop crashed! I didn’t have the time to dig into what, why and how.

Later in the day, I discovered my Elfeed’s DB was gone – blown away. :( I’m guessing the crash happened in the middle of elfeed-db-save, and the data was lost.

I’ve now added some back-up for the DB, since I intend to use Elfeed regularly.

(defvar pc/elfeed-db-save-timer nil
  "Timer for debounced elfeed database saves.")

(defun pc/elfeed-db-save-and-backup ()
  "Save the elfeed database and commit to git."
  (when (and (boundp 'elfeed-db) elfeed-db)
    (elfeed-db-save)
    (let ((default-directory elfeed-db-directory))
      (when (file-exists-p ".git")
        (call-process "git" nil "*elfeed-db-backup*" nil "add" "-A")
        (call-process "git" nil "*elfeed-db-backup*" nil "commit" "-m" "auto-backup")
        (call-process "git" nil "*elfeed-db-backup*" nil "push" "origin" "main")))))

(defun pc/elfeed-db-save-soon ()
  "Schedule a database save after 10 seconds of idle."
  (interactive)
  (when pc/elfeed-db-save-timer
    (cancel-timer pc/elfeed-db-save-timer))
  (setq pc/elfeed-db-save-timer
        (run-with-idle-timer 10 nil #'pc/elfeed-db-save-and-backup)))

;; Save and backup when tags change (elfeed-web usage)
(add-hook 'elfeed-tag-hooks   (lambda (&rest _) (pc/elfeed-db-save-soon)))
(add-hook 'elfeed-untag-hooks (lambda (&rest _) (pc/elfeed-db-save-soon)))

;; Save and backup when new entries are added
(add-hook 'elfeed-db-update-hook #'pc/elfeed-db-save-soon)

Some useful Git configuration for Windows

Fri, 24 Jan 2025 01:25:00 +0530

I’ve recently been working on Windows with a relatively involved git repository and ran into a bunch of issues. Setting these configuration values turned out to be very helpful!

# Allow symlinks
git config --global core.symlinks true

# Don't automatically change file endings to \r\n (carriage return + line feed)
git config --global core.autocrlf false

# Use line feed for line endings
git config --global core.eol lf

# Allow long paths in the repo
git config --global core.longpaths true

It’s also useful to set these as configuration values in .gitattributes in a repository to share this configuration with other people working on it.

Git resources : A post with some resources to better understand git, along with some useful git configuration.

My Favorite Git Resources

Fri, 22 May 2020 16:07:00 +0530

I often help friends who are new to using git with using it. This blog post is going to serve as a single link to share with them, instead of trying to find individual links over and over.

Understanding Git

I got started with using git after using svn and hg for a few months. But, I would often be lost in the myriad of command line options, putting myself in situations I couldn’t come out of without some scars. I didn’t really understand how git worked, and that was the real problem.

Improving my mental model of how git works, and then trying to fit the commands into this mental model is what made git finally click for me. The Git Parable really helped me understand git from the inside out, and gave me a much clearer mental model of git. There was no looking back from there.

If parables are not your thing, and you’d rather read something that takes a less flowery and more straighforward approach to explaining these concepts, I really liked John Wiegley’s Git from the Bottom Up.

Day-to-day git

Zulip (an open source group chat application that I spend a lot of time contributing to) uses a rebase-heavy workflow, where good commits are merged from different PRs, as and when they are reviewed, instead of waiting for all the commits in a PR to be good to be merged. Developers often have to pull from branches that have been force-pushed to, rebase their commits, squash commits, learn to change git history, etc.

Zulip’s Git Guide is top-class documentation that gives guidelines on using git from a practical stand-point. A lot of new developers use it to get upto speed with Zulip’s workflow that involves a lot of things that I’ve seen devs who have been using git for many years struggle with.

The section on pull request workflow is quite helpful, and should work reasonably well for contributing to other FOSS projects too.

I also like the sections with recipes for common git history edit actions, and the troubleshooting section with recipes to get out of common troublesome situations. Oh shit, git! is a very similar resource to this, that has a bunch of useful “recipes” to recover from different scenarios.

Julia Evans’s exercises approach to learning to explore a git repository is quite interesting, though I haven’t run through all the exercises myself.

Git as a communication tool

I like to look at git history as telling the story of evolution of a code base. The advice that is sometimes given to writers about doing the hardwork, so that the readers can do less of it, holds true for git history too. Communicate the story as clearly as possible for your readers to understand, and don’t just publish a “stream of consciousness” piece.

What does this mean in practical terms, though?

I think editing git history to present a clearer story is completely acceptable. If one tries a handful of different things, and then finally finds the solution to do something, it’s not necessary to have all the failed attempts as commits. Just the final approach can be a commit/pull-request, while documenting the other approaches the commit message or as a comment in the code, if that makes sense.

Expect your collaborators (including future you) to look at not just older versions of code, but the commit history for understanding how a piece of code evolved, for undertsanding the history. Make your git commit messages as useful as you can. Writing a good summary line goes a long way in understanding a change. In most cases a body would be useful to explain the how and the why of the change, while the summary line explains the what.

I like this commit discipline that the Git project itself uses, and was adopted by the Zulip project: “Each commit is a minimal coherent idea”. Simply put, you want each commit to be such that they can be can be deployed (and/or reverted by itself), without depending on any other commits alongside them. You can read more about what minimal and coherent mean in this context in the Zulip documentation.

Tools for Git

Some of the confusion in using git even after understanding how it works is the inconsitent CLI API that it often exposes. There has been some work going into this, to make this more consistent. But, using a nice client can help with this. I use the excellent Emacs client for git called magit. It is an intuitive UI on top of git’s data model, that allows me to do things that I commonly want to do, with just a few hot-keys, instead of typing out elaborate recipes to do things. I highly recommend it, if you are an Emacs user.

It is also helpful to change you shell’s prompt to tell you more about the status of the current directory’s repository. There are a bunch of configurations out there (Stackoverflow, Gists, etc.) that let you do this. The git repo itself comes with a prompt customisation. I like being able to see at least the current branch and dirty/clean state of the repo.

Here are some simple changes to the global git config, off the top of my head. These could make your git workflow more pleasant.

[push]
  # Push to the branch to the same remote branch as the one we are working on,
  # locally. This is the default in Git >= 2.0, so you may not need to set it.
  default = simple

[diff]
  # You could configure a GUI tool to use here. (I haven't used one in a long
  # time, and I don't have recommendations on what to use)
  tool = icdiff

[merge]
  # Shows common ancestor in a merge conflict. Makes it easier to understand
    # the conflict and merge, for me.
  conflictstyle = diff3

# Never garbage collect commits/blobs that are unreachable
# The cost of keeping this data around is negligble compared losing data
[gc]
  reflogExpire = never
  reflogExpireUnreachable = never

Outro

If you have other recommendations or tools that you’d like to share with me, please do! Using git better, and understanding it better, is something that I’m always excited about. I’d also be happy to answer questions, or help you with specific things that you are trying to do with git.

Recurse Center, 2014-06-23

Mon, 23 Jun 2014 04:38:29 -0400

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 git gc, 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 setting push.default to nothing will 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 jedi integration for 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 –
- Bret Victor, Inventing on Principle (54 min)
- Gary Bernhardt, WAT (4 min)
- Guy Steele, Growing a Language (53 min)

A git-diff tip

Wed, 22 Aug 2012 00:00:00 +0530

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 un-staged changes. --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

GetHub: Chrome Notifications for Github updates

Wed, 02 Mar 2011 00:00:00 +0530

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 username and 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: [2011-03-04 Fri] Added GetHub to the store

Comments and Feedback

Feel free to write to me at punchagan+gethub@jeemail.com
Or file issues at GitHub.

Happy GitHubbing!

Git powered wikis improved: My bit

Fri, 04 Feb 2011 00:00:00 +0530

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.

git vs. mercurial

Sun, 01 Aug 2010 00:00:00 +0530

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.