From: David Symonds Date: Sun, 23 Dec 2007 02:26:24 GMT Subject: Re: sane, stable renames; when a commit should commit twice Message-ID: In-Reply-To: <20071223020310.GA22450@freedbms.net> On Dec 23, 2007 1:03 PM, Zenaan Harkness 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.