Re: Minor annoyance with git push

From: Jeff King <peff@peff.net>
Date: Feb 9, 2008, 13:22 UTC
Message-ID: <20080209132209.GA20443@coredump.intra.peff.net>
In-Reply-To: <alpine.LSU.1.00.0802091302550.11591@racer.site>

On Sat, Feb 09, 2008 at 01:04:10PM +0000, Johannes Schindelin wrote:

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

I think the problem is that tests 7/8 in t5400 actually try to create a non-ff situation by doing a rewind. So it is not a bug in the new code so much as the test relied on the very behavior we changed.

Show 7 quoted lines

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

It's also slower than it needs to be, since we also do a ref_newer in the other direction, and because non-ff cases traverse all the way to the root. I think you could do better to write a function (similar to limit_list) which returned one of { A is an ancestor of B, B is an ancestor of A, A and B are equal, A and B are not directly related }, and you would have to traverse down only to the nearest merge base.

-Peff