Re: sane, stable renames; when a commit should commit twice

On Dec 23, 2007 1:03 PM, Zenaan Harkness [off-list ref] wrote:

When should a commit, commit twice?

When one or more git mv file renames/ moves are involved.

In such a case the commit ought to be split into two. Perhaps move the
files in the first commit, then make the changes needed to support the
move in the build chain (including changes in the moved files) in the
second commit.

This keeps a clean record of the move, making the move, and the
associated changes (as two commits) a clean cherry.

Does this make sense?

Not particularly. Git commits are not (conceptually) changes or
deltas; they are snapshots of a tree of files at a particular time.
How does the tree state at your above first commit make any sense? It
is broken. Git's rename/move detection is smart enough to notice that
a rename + small-changes is close enough to a rename, so just trust
that to get it right.


Dave.