Junio C Hamano <gitster@xxxxxxxxx> writes:
> But a more illustrative situation to consider is this. What if the change
> were not just "copy B/X to C/X", but was "concatenate the first half of
> B/X and the second half of C/X to create a new D/X".
A crucial question to the original poster was missing here:
If "a system that tracks provenance better than Git" wanted to record
something in such a situation, what does it record and how is the
recorded information used?
> As it happens, because our commit records the whole tree state and its
> parent commit, the "content provenance" of what is in D/X is precisely
> tracked. Look at the tree of the parent commit and look at the result,
> and you will notice the first half of D/X is identical to the first half
> of B/X before the commit and the second half of D/X is identical to the
> second half of C/X before the commit.
>
> In a situation where "provenance" is disputed, it does not matter if D/X
> was created by mechanically running
>
> head -n $n B/X >D/X
> tail -n $n C/X >C/X
Typo: "tail -n $n C/X >>D/x"
>
> or if you typed the file afresh. You could try to argue "No, your honour,
> I did not copy from these two files. I typed it myself from scratch and
> there is no plagiarism involved. They are all my words." But in the end,
> by comparing the tree state before your change and after your change, it
> would be very clear to any sane person that D/X is identical to the first
> half of B/X and the second half of C/X.
>
> Also see http://article.gmane.org/gmane.comp.version-control.git/217 aka
> one of the most important messages in the history of the Git mailing list
> for inspirations.
--
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