The Enterprise

Why sending patches via email is bad

Michael Pankov •

This week, I've received emails with source code changes thrice from different people. And at first I tried to persuade the colleague to commit changes to git instead, and failed. When I got changes by email third time this week, I decided to write a blog post about it.

Context

We work on same project and all have access to same git repository. There's no policy prohibiting arbitrary branch creation on server, but I generally remove old branches as they get merged. There's also no formalized changes review.
People who sent me changes did it in three forms:
  1. Just plain text source code in body of the email with comments like "I changed this place in that file to the following"
  2. Source code files, attached to the email message
  3. Patches, attached to the email message
I won't discuss the first two forms — they obviously indicate a decent amount of ignorance of good software engineering practices, but let's stop on the third one.

Why sending patches via email is bad

So, to send me changes, these people who sent me patches, did the following:
  1. Ran git format-patch in the working copy, with the revision interval specified. This is already unnecessary complicated — I'd rather not specify any revision interval. It also works only with established history, and I have no ways to, say, selectively share changes. In case of multiple commits it gets even more complicated on the receiving side — but let's talk about it later.
  2. Navigated to the folder where the patches are created.
  3. Created an email message, dragged-n-dropped patch files there.
  4. Sent the message.
And what I have to do to apply these changes:
  1. Open the email message, choose "Save as..." for each patch.
  2. Navigate to the location of the project to save patches there.
  3. Go to the terminal, use git apply for each patch, and hope the changes will apply successfully. At this point, I just have no information on from which branch were the patches made, so in case I'm working on a pretty divergent branch I'll have conflicts all over the place.
Let's compare this to a normal branching workflow. On the sending side:
  1. git checkout -b <issue name>
  2. git commit -a
  3. git push origin <issue_name>
On the receiving one:
  1. git fetch
  2. git checkout <issue_name>
I think it's pretty clear what is simpler and more precise.

Why using branches is good

Using distinct branch allows to review changes relative to upstream before merging, and still makes it clear that this is an independent unit of work.

Making the changes the independent unit of work matters, because you never know if it's only one commit. Maybe you broke something you didn't notice, maybe there's a cleaner solution, anyway — the receiving end will possibly build something on top of your changes, not just use it right from the shelf.

Please use branches, don't send patches.
comments powered by Disqus