On Jan 25, 8:54 pm, Luisgo <lgo...@gmail.com> wrote:
> How do you define a commit?
I liked the short blog entry at <http://who-t.blogspot.com/2009/12/on-
commit-messages.html>. It says that a commit should be “one logical
change” (similar to what others in this thread have written). It goes
on to mention some things a commit should not be (end of day
checkpoints, single file checkins when the change spans files,
multiple logical changes (multiple bugfixes, a bugfix and a
refactoring, etc.), a monolithic “code drop” that was developed
outside of the SCM).
In my opinion, you can still use Git to record incomplete work or end-
of-day states, but it is critically important that such commits never
enter the "official record" of a project's history. If you always work
in topic branches, it is easy to use tools like 'rebase' to rework and
cleanup your history until you have something that is clean, well
described, and ready to be merged with (or applied to) the official
Anyway, the main point of the blog entry is that you should always
spend time on commit log messages. The blog entry describes some
commit message qualities that have proven useful in existing projects.
Even with a DAG of nice, clean, cohesive commits, if they have useless
commit log messages, it will be very difficult to reconstruct the
context in which the commit was developed. A commit log message should
include answers to "Why is this needed?", "How does it address the
problem?", "What else does it impact?", but *not* "What changes does
this commit make?" (that answer is embodied by the ‘diff part’ of the
commit (leaving aside the fact that the core of Git does not really
deal in diffs or patches, but whole tree content)). The commit message
is there to record the context (even if the record is just to help the
original author remember the details of why a particular change was
made after not having looked at that part of the code for several
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at