Re: bisect / history preserving on rename + update

Junio C Hamano [off-list ref] writes:

Linus Torvalds [off-list ref] writes:

quoted

[ 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".

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