The Hackerlab at `regexps.com`

## Selected Files Commit

up: arch Meets hello-world next: Elementary Branches -- Maintaining Private Changes prev: Introducing replay -- An Alternative to update

Earlier, you learned how to commit all of the changes within a tree at once (see Checking-in Changes).

You also have read a bit about the importance of making "clean" changesets (see Using commit Well -- The Idea of a Clean Changeset).

This chapter shows you a little trick that you can use in a very specific but common situation.

### The Quick Fix Problem

Let's suppose that you have a large project tree and you're in the middle of making some complicated change. You've modified many files, but there are many others that you haven't touched.

Suddenly, you notice a trivial bug in one of the untouched files.

What you'd really like to do is:

1) Stop and fix the trivial bug.

2) Commit just that trivial bug fix.

3) Get back to work on the complicated changes.

How can you do that?

### The Brute Force Solution to the Quick Fix Problem

There's an easy "brute force" solution to the problem.

Simply:

Check out a fresh copy of the latest revision. In other words, create a second project tree with no modifications.

Fix the trivial bug in the new tree and commit. Now you've committed a clean change with just the trivial bug fix.

Use update or replay to Bring Your Original Tree Up to Date. That will add the trivial bug fix back to your tree with the partially completed changes.

That works, but it can be a little awkward. Do you really need to start a second project tree just to fix this trivial bug?

Sometimes the awkwardness is well worth it. For example, your project might have a policy the before every `commit` , you must run some tests. In that case, yes, you really do need a second tree.

Sometimes the awkwardness is nearly unavoidable. For example, if the trivial bug fix involves modifying files that you've already heavily modified, then again, the brute force technique may be the simplest approach (but also, take a look at `tla undo --help` and `tla redo --help` ).

But there is a simpler way that sometimes applies:

### Solving the Quick Fix Problem with commit --

As it turns out, `commit` lets you commit only the changes made to just a few files.

If your quick fix changes `file-a.c` and `file-b.c` , then after preparing a log message, you can commit just those files with:

            % tla commit -- file-a.c file-b.c

You should note that the files committed this way must not be new files and that, even if those files have been renamed, the `commit` will record only the changes internal to those files, not the renames.

### The Quick Fix Problem -- There's More Than One Way to Do It

In the text above, we speculated about a "brute force" solution to the quick-fix problem that involved checking out a whole new project tree.

Two other command, `tla undo` and `tla redo` , provide an alternative "brute force" solution with some advantages. These are described in a later chapter (see xref : !!! )../

arch Meets hello-world: A Tutorial Introduction to The arch Revision Control System
The Hackerlab at `regexps.com`