Friday, June 5, 2009

git patches from tarballs

Generating patches with git is easy if you clone upstream. Many users don't run their software from repositories. They work from either distribution packages or tarballs. So a number of times I've heard something along the lines of "Sorry, it's not a git patch because I'm working from the tarball". It is quite easy though to create git patches from your tarballs. Simply run the following command in the extracted directory:

git init && git add --ignore-errors .; git commit -m "`basename $PWD`"

  • "git init" initialises a new git repository.

  • "git add ." adds all existing files to the repo. The --ignore-errors is there so git skips over files that can't be added, I've had that happen in a few tarballs that had their permissions busted, etc. If there are errors, you obviously need to check whether they affect files you want to hack on. If not, ignore the errors. (btw. you want to run git add before compiling everything, having all object files in the git index is painful)

  • "git commit" commits all newly added files with the name of the current directory as commit message.

Now the directory is basically the same as upstream when they released the tarball, without the history. Either way, you can just hack, commit, rebase, etc. and then create a patch with git-format-patch and submit it to upstream. Assuming that upstream hasn't diverged too much from the tarball, chances are the maintainers can just apply the patch as-is.

Disclaimer: I learned this workflow from the Fedora X11 packages where this method is used to apply upstream patches to the tarballs. So the credit goes to ajax (or maybe someone else).

"git init-db" replaced with "git init".


Anonymous said...

Dude, git init-db is ancient, use 'git init'.

Anonymous said...

That's a really nice trick, I'm surprised I never thought of it before. Thanks for posting it!

spbnick said...

Thanks for the hint :)!