Jump to content

What--Git with patches? A 1980s technology?

  andyo's Photo
Posted Oct 02 2009 11:01 AM

Many of us used Larry Wall's ubiquitous patch(1) program constantly before we had reliable Internet connections and version control. Now it seems like a relic of an ancient religion. But emailing and applying patches is quite common in the Git community (although not using Larry's program). Version Control with Git contains a whole chapter on patches. The following excerpt explains why you'd consider using them.


Although the Git protocol is much more efficient, there are at least two compelling reasons to undertake the extra effort required by patches (one is technical and the other is sociological).

  • In some situations, neither the Git native protocol nor the HTTP protocol can be used to exchange data between repositories in either a push or a pull direction or both.

    For example, a corporate firewall may forbid opening a connection to an external server using Git's protocol or port. Additionally, SSH may not be an option. Moreover, even if HTTP is permitted, which is common, you could download repositories and fetch updates but not be able to push changes back out. In situations like this, email is the perfect medium for communicating patches.
  • One of the great advantages of the peer-to-peer development model is collaboration. Patches, especially those sent to a public mailing list, are a means of openly distributing proposed changes for peer review.

    Prior to permanently applying the patches to a repository, other developers can discuss, critique, rework, test, and either approve or veto posted patches. Since the patches represent precise changes, acceptable patches can be directly applied to a repository.

    Even if your development environment allows you the convenience of a direct push or pull exchange, you may still want to employ a "patch email review apply" paradigm to gain the benefits of peer review.

    You might even consider a project development policy whereby each developer's changes must be peer-reviewed as patches on a mail list prior to directly merging them using git pull or git push. All the benefits of peer review together with the ease of pulling changes directly!

And there are still other reasons to use patches.

In much the same way that you might cherry-pick a commit from one of your own branches and apply it to another branch, using patches allows you to selectively choose commits from another developer's repository without having to fully fetch and merge everything from him.

Of course, you could ask the other developer to place the desired few commits on a separate branch and then fetch and merge that branch alone, or you could fetch his whole repository and cherry-pick the desired commits out of the tracking branches. But you might have some reason for not wanting to fetch the repository, too.

If you want an occasional or explicit commit--say, an individual bug fix or a particular feature--applying the attendant patch may be the most direct way to get that specific improvement.

1 Subscribe

0 Replies