Nicolas Pitre <nico@xxxxxxx> writes:
> Still, in your case, you probably won't get rid of your stable branches,
> hence the reachability argument is rather weak for your usage scenario,
> meaning that you could as well have that info in the free form text
> (like cherry-pick -x), and even generate a special graft file from that
> locally for visualization/blame purposes. Sure the indirection will add
> some overhead, but I doubt it'll be measurable.
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.
Without any "origin", here is how blame works:
* What Z did is blamed on Z; what Z did not change is passed to Y;
* Y needs to:
(1) take responsibility for what it changed; and/or
(2) the remaining contents came from X --- pass the blame to it.
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.
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.
IOW, you did not look at the contents outside "diff A..B" when you made
the cherry-pick. There could well be parts of the content that are common
across all of A, Y, X and Z, but as far as Y and Z are concerned, they did
not get any part of that common common content from A (otherwise "origin"
is no different from "parent", but you did not merge).
The output from "origin" aware blame would be identical to the normal
blame, except that lines that usually are labeled with Y are labeled with
B. However:
(1) If you _are_ interested in the line that says Y, you can look at
the commit object Y and see "cherry-pick -x" information to learn
it came from B already; and
(2) More importantly, if you want to dig deeper by peeling the blamed
line (I think gitweb allows this, and probably git-gui), you
shouldn't peel that line blamed on B to start running blame at A.
That would continue digging the history of A, which is wrong when
you are examining the history that led to Z.
So please leave "blame" out of this discussion.
--
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
