Re: bisect / history preserving on rename + update

From: David Kastrup <dak@gnu.org>
Date: Aug 14, 2007, 11:12 UTC
Message-ID: <86wsvyfjyg.fsf@lola.quinscape.zz>
In-Reply-To: <1187089619.12828.183.camel@chaos>

Thomas Gleixner <tglx@linutronix.de> writes:

Show 27 quoted lines

> On Tue, 2007-08-14 at 12:50 +0200, Karl Hasselström wrote:
>> > Err.
>> >
>> > git-mv A B
>> > git commit
>> > edit B
>> > git commit
>> > git blame B <- shows the full history of A & B
>> >
>> > IMHO that's why we have git-mv
>> 
>> Try replacing
>> 
>>   $ git-mv A B
>> 
>> with
>> 
>>   $ mv A B
>>   $ git rm A
>>   $ git add B
>> 
>> The result is exactly the same. git-mv is just a convenience.
>
> Fair enough, but it still does not solve my initial problem of keeping
> the history of B (former A) intact, while creating a new A which is
> necessary to compile the tree, simply because I can not change #include
> <A> to #include <B> for various reasons.

Sigh. Please use the right options for calling your history viewing commands. It is not like I haven't told you that already. For example, take git-blame. Its manual page clearly states:

	-M|<num>|
	   Detect moving lines in the file as well. When a commit
	   moves a block of lines in a file (e.g. the original file
	   has A and then B, and the commit changes it to B and then
	   A), traditional blame algorithm typically blames the
	   lines that were moved up (i.e. B) to the parent and
	   assigns blame to the lines that were moved down (i.e. A)
	   to the child commit. With this option, both groups of
	   lines are blamed on the parent.

	   <num> is optional but it is the lower bound on the number
	   of alphanumeric characters that git must detect as moving
	   within a file for it to associate those lines with the
	   parent commit.

	-C|<num>|
	   In addition to -M, detect lines copied from other files
	   that were modified in the same commit. This is useful
	   when you reorganize your program and move code around
	   across files. When this option is given twice, the
	   command looks for copies from all other files in the
	   parent for the commit that creates the file in addition.

	   <num> is optional but it is the lower bound on the number
	   of alphanumeric characters that git must detect as moving
	   between files for it to associate those lines with the
	   parent commit.

-- 
David Kastrup