On Wed, Jan 16, 2013 at 08:19:28PM -0600, Chris Rorvick wrote:
> On Wed, Jan 16, 2013 at 11:43 AM, Jeff King <peff@xxxxxxxx> wrote:
> > 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
--
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