On Thu, Jan 17, 2013 at 7:06 PM, Jeff King <peff@xxxxxxxx> wrote: > However, if instead of the rule being > "blobs on the remote side cannot be replaced", if it becomes "the old > value on the remote side must be referenced by what we replace it with", > that _is_ something we can calculate reliably on the sending side. Interesting. I would have thought knowing reachability implied having the old object in the sending repository. > And > that is logically an extension of the fast-forward rule, which is why I > suggested placing it with ref_newer (but the latter should probably be > extended to not suggest merging if we _know_ it is a non-commit object). Sounds great, especially if it is not dependent on the sender actually having the old object. Until this is implemented, though, I don't understand what was wrong with doing the checks in the is_forwardable() helper function (of course after fixing the regression/bug.) Chris -- 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