On Wed, 18 Dec 2013 02:18:10 -0800 (PST)
THUFIR HAWAT <hawat.thu...@gmail.com> wrote:
> It seems potentially problematic to commit a single source code file,
> and not all source code. Potentially, for example in Java, the
> project might not even compile.
> What circumstance(s) would a single necessitate a single file commit?
Yes, this is potentially problematic but only potentially.
First, you might use Git to track not the source code of a program but
something else completely like, say, a set of PDF files.
Second, a typical attitude to the project's history (for instance,
sported by the developers of Linux and Git, which is not surprising)
is that only the *published* (or sent in the form of a patch series)
history is sacred but your *local* history is not. The sense of this
motto is that it's perfectly OK to record a series of sloppy piecemeal
commits on a branch to later squash them into one or more beautiful
*tested* commits, using the `git rebase` tool.
That is, to commit a single file or not to commit should not be
perceived as a dogma. If you define for your project a policy that
each commit must be compilable (say, to ease bisecting later), then
follow that policy by ensuring each commit is compilable. If not,
then, uh, do not follow it. As simple as that. In other words,
"the compilability" of a project is not something Git itself should be
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.