What is the differences between committing and patching?

Question

I am quite new to source control and would like to know the differences between committing and patching? Also, how/when a patch is use and can it be used on a web application?

Answer 1

I'm not sure about git/mercurial, but here is what I think based on what I know about CVS, since I've used patches only there, though I'm pretty sure it works/is used the same way.

When you "commit", you effectively override the remote version of the file with the one on your local repository. What you commit is in fact a "patch".

A patch is a file containing the set of differences between two version of one or more files.

Patching is when you get a patch from someone else (say, by email for example), in order to be able to merge your local version with the version of the person that submitted the patch, while not merging with the version on the remote repository. This often happens because the person that provided you the patch has no write authorizations to the repository.

So basically, a person can create a patch containing the set of differences of one, or multiple files between two versions. And another person can apply the patch to its own version and then commit the patch to the repository.

As to why it is used, the scenario I described above when one person has no access is valid. Another use is that you can give/commit patches if you don't want to commit the whole changes you made. For example, you made three changes to one file, but the last change is some debugging code that is not destined to be committed, so you create a patch, you remove the last change from the patch file, and your patch is ready to be sent/committed.

Finally, as for your last question, it can be used for any type of application where the code is stored in a repository.

Edit: A concrete example: you can submit a patch to fix a Github project where you don't have write access.

Answer 2

Patch can be applied anywhere -- to a working copy, or to a repository. It's just a file format that lists the changes necessary to bring code from one state to another. Version control need not be involved.

A commit saves a set of code changes (similar to what a patch references) to the source code repository (e.g. Mercurial/Git repo). From there, whenever anyone checks out the latest code it will include that commit.

Answer 3

I can understand your confusion, the two words are closely related. There is a glossary for Mercurial that says:

• Patch (noun) The product of a diff operation.

  Example: "I've sent you my patch."

• Patch (verb) The process of using a patch file to transform one changeset into another.

  Example: "You will need to patch that revision.

• Commit (noun) A synonym for changeset.

  Example: "Is the bug fixed in your recent commit?"

• Commit (verb) The act of recording changes to a repository. When files are committed in a working directory, Mercurial finds the differences between the committed files and their parent changeset, creating a new changeset in the repository.

  Example: "You should commit those changes now."

So, to elaborate a bit: a patch is a description of changes between two versions/changesets. You get that description with hg diff and it looks like this:

diff --git a/x b/x
--- a/x
+++ b/x
@@ -1,3 +1,3 @@
 a
-old line
+new line
 b

The patch is in unified diff format. This is a machine-readable format so Mercurial can apply a patch to make the same changes somewhere else — Mercurial can use the patch to patch your code.

When you've made changes to your files, you can commit the changes with hg commit. This creates a new changeset (which is also known as a commit). As you can see from the glossary, a changeset records the differences between the committed files and the parent changeset — this is a patch. So a changeset will have a patch inside, plus other information such as committer name, date, and message.

A patch is often used when you need to discuss code with a coworker. You can send him a patch in an email and he can review it. You can also use a patch if you want to modify a file with committing the change — for a webapp, you could have a patch with your local customizations. When you get a new version of the app, you first remove the patch, update the app, and then re-apply the patch. That way you can maintain your customizations as a patch on top of the original source code.