Re: [PATCH 7/7] push: clarify rejection of update to non-commit-ish

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Chris Rorvick <chris@xxxxxxxxxxx> writes:

> Pushes must already (by default) update to a commit-ish due the fast-
> forward check in set_ref_status_for_push().  But rejecting for not being
> a fast-forward suggests the situation can be resolved with a merge.
> Flag these updates (i.e., to a blob or a tree) as not forwardable so the
> user is presented with more appropriate advice.
>
> Signed-off-by: Chris Rorvick <chris@xxxxxxxxxxx>
> ---
>  remote.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/remote.c b/remote.c
> index f5bc4e7..ee0c1e5 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -1291,6 +1291,11 @@ static inline int is_forwardable(struct ref* ref)
>  	if (!o || o->type != OBJ_COMMIT)
>  		return 0;
>  
> +	/* new object must be commit-ish */
> +	o = deref_tag(parse_object(ref->new_sha1), NULL, 0);
> +	if (!o || o->type != OBJ_COMMIT)
> +		return 0;
> +

I think the original code used ref_newer() which took commit-ish on
both sides.

With this code, the old must be a commit but new can be a tag that
points at a commit?  Why?

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]