Stephen R. van den Berg wrote:
>Junio C Hamano wrote:
>>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?
I'm sorry, you're right, I'm confusing things here. The case I'm describing
here can only happen when you do this:
....-C---D---E---F---G
\...\...\..\ (origin)
.
...---A---B
. (origin)
.
...---o---X---Y---Z
I.e. the first cherry-pick needs to cherry-pick C, D, E *and* F into B,
that will result in four origin fields there.
And yes, that means that:
- blame follows origin links (repeatedly).
- blame does *not* travel to parents of commits found through an origin
link.
Does that mean that blame uses origin fields? Yes, it does, and it has
to check for origin links at every commit it traverses.
--
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
