On Dec 23, 2007 1:03 PM, Zenaan Harkness <zen@xxxxxxxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
