On Mon, Apr 24, 2017 at 10:33:11PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Anyway. I don't think Miguel's patch needs to solve all of the lingering
> > rename cases. But I am curious whether it makes some rename cases worse,
> > because the depth-sorting was kicking in before and
Jeff King writes:
> Anyway. I don't think Miguel's patch needs to solve all of the lingering
> rename cases. But I am curious whether it makes some rename cases worse,
> because the depth-sorting was kicking in before and making them work.
I agree with you on both counts, and I care more about t
On Mon, Apr 24, 2017 at 09:24:59PM -0700, Junio C Hamano wrote:
> > So we sort deletions first. And the bit that the context doesn't quite
> > show here is that we then compare renames and push them to the end.
> > Everything else will compare equal.
>
> Wait--we also allow renames? Rename is li
Jeff King writes:
> Perhaps we would want a test for the case you are fixing (to be sure it
> is not re-broken), as well as confirming that we have not re-broken the
> original case (it looks like 060df62 added a test, so we may be OK with
> that).
Good suggestion.
>
>> +/*
>> + * Compares two
On Tue, Apr 25, 2017 at 02:12:16AM +0200, Miguel Torroja wrote:
> The delete operations of the fast-export output should precede any addition
> belonging to the same commit, Addition and deletion with the same name
> entry could happen in case of file to directory and viceversa.
>
> The fast-expo
5 matches
Mail list logo
