Re: [PATCH 6/8] apply: fall back on three-way merge

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

 



Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:

> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> +	/* Preimage the patch was prepared for */
>> +	if (get_sha1(patch->old_sha1_prefix, pre_sha1) ||
>> +	    read_blob_object(&buf, pre_sha1, patch->old_mode))
>> +		return error("repository lacks necessary blobs to fall back on 3-way merge.");
>
> What happens if there are multiple objects for the same pre_sha1?

We probably would not get anythning out of get_sha1() due to ambiguity and
we would punt.

We could inroduce get_all_possible_sha1_among_ambigous_ones() to grab an
array, try to apply and use the first one, but I do not know if it is
really worth the effort. The usefulness of -3 is limited to only two cases
in practice, and neither case gives you a big chance of seeing such a
collision.  Either you are applying a patch from others that was based on
something you shared with them in the past, hence it is very likely that
you and they shared a very similar set of objects that determined the
length of the abbreviated object name shown on the "index" line, in which
case the chance of ambiguity is not that great, or you are using the diff
to apply pipeline in a workflow similar to the ones I recently described
in messages in another thread, in which case the patch is taken from your
own repository and the length of the abbreviated object name shown on the
"index" line is determined not to be ambiguous in the first place.

If we happened to grab totally unrelated pre_sha1, the patch won't apply,
and we would not cause any damage.

An interesting point that is worth noting is that if we happened to grab a
pre_sha1 that is different from what the original patch was based on, it
does not introduce a mis-apply risk, either.  We only fall back to the
merge after making sure the patch applies to the "original" (which may not
be exactly what the patch was based on), which ensures that the preimage
shown in the hunks of the patch match.  Because the application of the
patch to the "original" found will by definition only modify the part that
is shown in the hunks of the patch, any difference between the preimage
we find and the true preimage the patch was based on will cancel out in
the three-way merge step.
--
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]