Re: [RFC] origin link for cherry-pick and revert

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 11, 2008, 21:05 UTC
Message-ID: <7vy71ys8a7.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.LFD.1.10.0809111222170.23787@xanadu.home>

Nicolas Pitre <nico@cam.org> writes:

Show 6 quoted lines

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