Jakub Narebski wrote: > 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"). Scratch that. It would be better for merge strategy just to check for defined set of "links" and "notes", e.g. "prior" (pu-prior) and "original" (cherrypick). But there would be problem with connectivity provided by "link" relations, namely info/grafts file, which deal only with parents. For example when we cauterize history using grafts (e.g. for shallow clone) the "link" like "prior" reaching to the cut-off part of the history might make your day ;-) Well, we could always drop all the connectivity, and make link sha1 description... shortcut for note link sha1 description... -- 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