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

On Wed, Jan 16, 2013 at 08:19:28PM -0600, Chris Rorvick wrote:

On Wed, Jan 16, 2013 at 11:43 AM, Jeff King [off-list ref] wrote:

quoted

I think that is a reasonable rule that could be applied across all parts
of the namespace hierarchy. And it could be applied by the client,
because all you need to know is whether ref->old_sha1 is reachable from
ref->new_sha1.

is_forwardable() did solve a UI issue.  Previously all instances where
old is not reachable by new were assumed to be addressable with a
merge.  is_forwardable() attempted to determine if the concept of
forwarding made sense given the inputs.  For example, if old is a blob
it is useless to suggest merging it.

I think it makes sense to mark such a case as different from a regular
non-fast-forward (because "git pull" is not the right advice), but:

  1. is_forwardable should assume a missing object is a commit not to
     regress the common case; otherwise we do not show the pull advice
     when we probably should, and most of the time it is going to be a
     commit

  2. When we know that we are not working with commits, I am not sure
     that "already exists" is the right advice to give for such a case.
     It is neither "this tag already exists, so we do not update it",
     nor is it strictly "cannot fast forward this commit", but rather
     something else.

     The expanded definition of "what is a fast forward" that I
     suggested would let this fall naturally between the two.

-Peff