@need 3200

@node Selected Files Commit
@chapter Selected Files Commit

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


You also have read a bit about the importance of making "clean"
changesets (see @strong{Using commit Well -- The Idea of a Clean Changeset} in @ref{Exploring Changesets}).


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

@need 3200

@section 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 @emph{@strong{in one of the untouched files}}.


What you'd really like to do is:


@strong{1)} Stop and fix the trivial bug.


@strong{2)} Commit just that trivial bug fix.


@strong{3)} Get back to work on the complicated changes.


How can you do that?




@need 3200

@section The Brute Force Solution to the Quick Fix Problem

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


Simply:


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


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


@strong{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 @emph{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 @code{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 @code{larch undo --help} and @code{larch redo
--help}).


But there is a simpler way that sometimes applies:




@need 3200

@section Solving the Quick Fix Problem with commit --files

As it turns out, the @code{commit} command has an option @code{--files} that
let's you commit only the changes made to just a few files.


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

@example
@group
        % larch commit --files -- file-a.c file-b.c
@end group
@group
@end group
@end example

You should note that the files committed by @code{commit --files} must not
be new files and that, even if those files have been renamed, the
@code{commit} will record only the changes internal to those files, not the
renames. 







