Re: bisect / history preserving on rename + update

From: David Kastrup <dak@gnu.org>
Date: Aug 25, 2007, 07:35 UTC
Message-ID: <85r6lsdq23.fsf@lola.goethe.zz>
In-Reply-To: <7vmywgb45c.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 25 quoted lines

> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> [ However, there does seem to be a bug in the "-B" logic, so it doesn't 
>>   actually work as well as it should! See below ]
>
> I finally had a bit of time to follow this through.  After
> running your set-up using revision.c and Makefile to emulate the
> situation, you can try running:
>
> 	$ git diff-tree -B -C --numstat --summary HEAD
>
> or
>
> 	$ git diff-tree -B -M --numstat --summary HEAD
>
> which would say:
>
>         90028d007986de4db8c3af30a2d5e5c00e5a2c8b
>         0       0       revision.c => old-revision.c
>         1117    1579    revision.c
>          rename revision.c => old-revision.c (100%)
>          rewrite revision.c (98%)
>
> The code is working as intended (it is a different discussion if
> "as intended" is actually the desired behaviour).

>From reading the argument of Linus, I would say that this "stateless,

not applicable by patch" behavior is desirable in some application. And the "sequential, applicable by patch" behavior also is desirable in a number of applications.

So there should be an option to select those behaviors. This has the added advantage that the manual page will explain that option, and so the user gets to actively pick what he wants, and gets to _think_ about this choice.

This would be strictly better than "at some point of time, we figured that this particular way suited Linus' personal workflow best, so we obliterated all traces of other applications from code, documentation, discussion and thought".

Show 8 quoted lines

> This behaviour actually was a bit counterintuitive to me.  I did
> not implement the very original rename/copy the way we currently
> operate.  It was corrected into the current behaviour, following
> the guiding principle described in this message:
>
> 	http://thread.gmane.org/gmane.comp.version-control.git/3807
>
> which is reproduced below.

I think this is a case where restricting git's operation to a single way of doing it is limiting the range of its applications. And having _neither_ an option _nor_ an explanation but rather pretending that this is the only valid way one could want this feature to work is not going to help even those users who would, in the end, decide to choose that behavior after all.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum