Hi,
On Fri, 8 Feb 2008, Jeff King wrote:
> 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.
> @@ -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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
