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.
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?
There's an easy "brute force" solution to the problem.
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
, 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
But there is a simpler way that sometimes applies:
As it turns out,
lets you commit only the changes made to just a few files.
If your quick fix changes
, 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
will record only the changes internal to those files, not the
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,
, provide an alternative
"brute force" solution with some advantages. These are described
in a later chapter (see xref :