Hi,

On Fri, 8 Feb 2008, Jeff King wrote:

quoted text
> On Fri, Feb 08, 2008 at 09:46:36PM -0500, Jeff King wrote:
> 
> > > The local side has the remote refs if the client has fetched recently,
> > > so it might be able to tell in some cases. Not with authority (things
> > > may have changed on the server side...) but the client might be able
> > > to say something less alarming.
> > 
> > This is actually not that hard to do in the case that we can. Patch will
> > follow in a second, though I am not sure it is a good idea (because it
> > silently ignores pushing rewinds).
> 
> And here it is. Again, I don't think this is the right default behavior.
> I'm not even sure it is a good idea as configurable behavior. But it's
> here for comment and for playing with, nonetheless.

I was already trying to make a patch on top of yours which says "[stale]" 
instead of "[rejected]" for those cases, but then I realised that 2 tests 
in t5400 fail.

quoted text
> @@ -463,8 +467,12 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest
>  		    (!has_sha1_file(ref->old_sha1)
>  		      || !ref_newer(new_sha1, ref->old_sha1));
>  
> +
>  		if (ref->nonfastforward && !ref->force && !args.force_update) {
> -			ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
> +			if (ref_newer(ref->old_sha1, new_sha1))
> +				ref->status = REF_STATUS_REJECT_REWIND;
> +			else
> +				ref->status = REF_STATUS_REJECT_NONFASTFORWARD;

Indeed.  I did not think it was that easy, but apparently it is.

Thanks,
Dscho
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html