git

Changing what commit a git submodule points to without initializing it

cbLeave a comment

Let’s say you have a submodule that you want to change, but the submodule itself is huge. You might not want another copy of it, so you’re holding off on running git submodule update --init. Internally in your repo, Git records the commit that the submodule points to. If you have the exact commit ID, you can run this command to adjust it points to in the index (substituting the hash for the commit ID you want to change it to, and of course, the path to the submodule):

git update-index --add --cacheinfo  160000,4435a55c4c352d5c703cab322c208ca4dce14ae8,submodule_name_here

This is added to the index, so you’ll have to commit your change as normal.

It never had to be like this: the git “index”

cb2 Comments

Hot on the heels of another Git-related article that was making the rounds recently, I was reminded of Git’s own structure and how it influences user experience. Specifically what we assume is part of how Git works, is actually a part of the porcelain (in Git speak, the user interface and commands that back it). As someone developing a Git client, it’s interesting to think Git’s user experience could be significantly different with a different interface, particularly because people have a particular mental model of Git influenced by the default interface. Said influence is enough that libgit2’s API emulates the porcelain’s semantics, in-process.

Continue reading →