Re: [PATCH v6 0/8] push: update remote tags only with force

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 18, 2013, 04:36 UTC
Message-ID: <7vfw1zrttq.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130118010638.GA29453@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 5 quoted lines

> 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,...

It may be an extension of the fast-forward, but only in the graph reachability sense. I can buy that it is mathmatically consistent with the mode that has proven to be useful for commits at the branch tips, which we know why "fast-forward" rule is an appropriate default for. You haven't shown if that mathmatical consistency is useful for non-commit case.

The primary reason "fast-forward" is a good default for branches is not that "we do not want to lose objects to gc" (you have reflog for that). The reason is non fast-forward is a sign of unintended rewind, and later will cause duplicated history with merge conflicts.

That comes from the way objects pointed by refs/heads aka branches are used. It is not just "commit" (as object type), but how these objects are used. Think why we decided it was a good idea to do one thing in the topic that introduced the regression under discussion: "Even if the new commit is a descendant of the old commit, we do not want to fast-forward a ref if it is under refs/tags/". Type of object may be one factor, but how it is used is more important factor in deciding what kind of policy is appropriate.

If users have workflows that want to have a ref hierarchy that point at a blob, there will not be any update to such a ref that will satisfy your definition of "extended" fast-forward requirement, and that requirement came solely from mathematical purity (i.e. graph reachability), not from any workflow consideration. That is very disturbing to me.

A workflow that employes such a "blob at a ref" may perfectly be happy with replacing the blob as last-one-wins basis. I do not think the client side should enforce a policy to forbid such a push.

I personally think the current client side that insists that updates to any ref has to have the current object and must fast-forward and requires --force otherwise was a mistake (this predates the change by Chris). The receiving end does not implement such an arbitrary restriction outside refs/heads/, and does so only for refs/heads/ only when deny-non-fast-forwards is set.