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

From: Jakub Narebski <jnareb@gmail.com>
Date: Dec 23, 2007, 16:29 UTC
Message-ID: <fkm2ck$o8j$1@ger.gmane.org>
In-Reply-To: <ee77f5c20712221826r5945a6d0x8a84eae98c85b25b@mail.gmail.com>

David Symonds wrote:

Show 21 quoted lines

> On Dec 23, 2007 1:03 PM, Zenaan Harkness <zen@freedbms.net> 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.

Moreover renames detection during merges is based on three states: ours, theirs and ancestor, and it would not take into account "pure rename" commit it is there in the middle of one of chains.

Besides broken (not compiling) commit makes it harder for bisect to find true bug later.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git