On Thu, Jan 17, 2013 at 07:09:16AM -0600, Chris Rorvick wrote: > I was referring to your concern about rejecting based on type. A push > causing a reference to move (for example) from a commit to a blob is > rejected as "already exists" with this patch. You emphatically state > this is not OK and your solution is to revert back to behavior that > advises a merge. > > Clearly the bug regarding an 'old' unknown to the client should be > fixed. This is a obvious test case I should have covered and it's > unfortunate it made it into master. But I don't understand why > is_forwardable() was misguided (maybe poorly named) nor why > ref_newer() is a better place to solve the issues it was addressing.
I think that a type-based rule that relies on knowing the type of the other side will always have to guess in some cases, because we do not necessarily have that information. 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. 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). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
