> In order to reach that goal, changes need to be identifiable and immutable.
> If you don't like a change, as is frequently the case, then the remedy it
> to make another change on top of the previous change. That's what peope
> do when they edit the diffs. But you can not edit the diffs and apply the
> diffs as **one change**. It has to be two changes - the original, immutable
> change, plus the second change. If it works like that, then you can automate
> the task of figuring out if a change is in Linus' tree. If it doesn't work
> like that, you have no choice but to go read the code and see if it is in
> there - there is not a prayer of automating it because you can't tell how
> much has been changed by someone editing the diffs.
one thing that automatically prevents editing (or corrupting) patches is
to sign the patch on the sender side. (md5 or PGP?)
> All that said, you still want your context diffs. You can have them.
> The diff -n is just what the system uses to pass the changes between
> repositories. *Nothing* goes into a repository before you have a
> chance to look at the diffs, any diffs you want - context, unified,
> sdiff, graphical file merge, whatever. What you lose is the ability
> to screen in your mail box. If you must have this, I can emulate this.
i think added redundancy in the protocol also increases reliability.
Instead of silently corrupting the repository, it will at least have a
chance to detect the conflict. (conflict here is not a 'natural' conflict
between two developers, but a conflict created by some other software
component/bug) [of course, if i understand it correctly, this is purely an
internal matter of the repository, so it's up to you.]
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/