Junio C Hamano wrote: > Jakub Narebski <jnareb@xxxxxxxxx> writes: > >> Actually, this can be resolved using automatic history grafts to the >> remote repository we pulled from, if the commit is not present on local >> side (and removing graft when commit appears on local side). > > You do not even need history grafts. The "cherry-pick source" > was a bad example. Maybe using "related" as a way to implement > "bind" would have been a better example -- we want inter-commit > relationship that requires connectivity but without ancestry for > them. > > You can just have two kinds of 'related'. One that means > connectivity, the other that does not. Good idea. Another problem for core git, but I think orthogonal to the "related"/"note" distinction is if the relation (or note) should be used as helper in merges, perhaps by some agreed upon convention on the comment/description/value part (e.g. "mergehelper" or "mergeinfo"). BTW. in your first example, what "key" relation should mean? "cherrypick" (which should be "note" as we don't need connectivity) is quite obvious (or equivalent "origin" if rebase wouldn't destroy the branch picked from). -- Jakub Narebski Warsaw, Poland - : 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