> I meant the project's history, not the meta-graph thing. In that case, we agree. The proposal suggests that "origin" should be reachable from the meta-graph for the cherry-picked commit, NOT the cherry-picked commit itself. Does that resolve our disagreement, or is reachability from the meta-graph also undesirable for you?
> By having a "this was cherry-picked from that commit" in a commit > that is not GC'ed, the original commit that has no longer have any > relevance (because the newer one that is the result of the > cherry-pick is the surviving version people will be building on) is > kept reachable. It is very much delierate that "cherry-pick -x" > does not make the "origin" reachable and merely notes it in the > human readable form that is ignored by the reachablity machinery. Hmm. It sounds like you may be arguing against reachability from the cherry-picked commit (which we agree on). I'm arguing for reachability ONLY from the meta-graph. From your reply it's not completely clear to me whether you also disapprove of reachability from the meta-graph or if you thought the origin edges would be present on the cherry-picked commit itself. Could you clarify? I suspect it may be the latter, which suggests ambiguity in the proposal. If you could point to the text that gave the impression origin parents would be present in the cherry-picked commits themselves, I'll fix it. > This is where we differ. If commit X was rewritten (perhaps with > help from change cherry-picked from commit Z, or without any) to > produce Y, I do agree that it would be logical to keep X around > until every dependent commit on it are migrated to be on top of Y. The scenario you describe would not produce an origin edge in the metacommit graph. If the user amended X, there would be no origin edges - just a replacement. If you cherry-picked Z you'd get no replacements and just an origin. In neither case would you get both types of parent. I'd suggest we focus on the cherry-pick scenario since it's the simplest real-world use case that produces origin parents. All the more complex scenarios involving both parent types only occur if you start from that simple case, so if you convince me that the origin-only use case is unnecessary or undesirable, it would also follow that the more complex origin-plus-obsolete-parent use case is unnecessary. So, if you don't mind - let me simplify that use-case: "If commit Z is cherry-picked to produce Y, is there any need to keep Z around?". I don't think we need X in the example to answer that question. > But we do not need Z to transplant what used to be on X on top of Y, > do we? That's correct. The origin parent would be used to incorporate amended versions of Z into Y, not to transplant things. It would also be used to locate ancestors when merging code based on Z with code based on Y. > So I do agree that in such a situation they want the > relevant parts of the history retained, but I do not agree that > "origin" is among them. You may be entirely right, but at this point I'm not certain whether we're disagreeing or miscommunicating. :-(
