Junio C Hamano wrote:
>I keep hearing "blame" in this discussion, but I do not understand why
>people think blame should _follow_ this "origin" information (in the usual
>sense of "following").
>Suppose you cherry-pick an existing commit from unrelated context:
> ...---A---B
> . (origin)
> .
> ...---o---X---Y---Z
>i.e. on top of X the difference to bring A to B is applied to produce Y,
>and a new development Z is made on top. You start digging from Z.
>Let's see how we would want "origin" get involved. Instead of the above,
>what Y would do would be:
> (1) if the contents (excluding the part Z changed) is different from X,
> instead of taking the blame itself, give the _final_ blame to B.
> (2) the remainder is passed to X as usual.
Sounds reasonable.
>This is different from the normal "following" in that B is not allowed to
>pass the blame to its parents (should it be allowed to pass it to its
>"origin"?), because the _only thing_ cherry-pick did was to transport what
>B did (relative to A) to the unrelated history that led to X.
Well, I'd expect:
a. That B should be able to pass blame onto it's origin.
b. That B should be able to pass blame onto A (and deeper).
Let me show another example:
...-C---D---E---F---G
. (origin)
.
...---A---B
. (origin)
.
...---o---X---Y---Z
Now suppose there is a piece of sourcecode which evolves from C to F,
then when I dig into G using blame I get something like: CCCFFEGGDDDCC
(Every letter represents a line in the sourcecode)
Digging into Z I'd expect to see the following: ZZCCCFFEDDYDCCB
All this assumes that there were minimal changes to the patch when
creating B, and also minimal changes to the patch when creating Y.
I.e. large parts of that code where developed during C, D, E and F, so
that is what I expect to see; is that illogical?
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
--
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
