On Tue, 17 Apr 2007, Andy Parkins wrote: > On Tuesday 2007 April 17 11:09, Junio C Hamano wrote: > > > In http://article.gmane.org/gmane.comp.version-control.git/44654, > > Linus said: > > And *I* claim that if you don't get an immediate and empty diff, your > > system is TOTALLY BROKEN. > > Well that one is easy - the file is normalised to contain collapsed keywords > upon checkin, so diff works the same as it ever did. The output would be > immediate and empty so is not TOTALLY BROKEN. No, it *is* TOTALLY BROKEN, because your keywords guaranteed that it doesn't even *apply*. That's such a fundamental part of a patch that I didn't even _mention_ it, but I obviously should have. If you cannot apply the diff you generate, what the hell is the *point* of a diff? Try this: - File-A in revision 1: $ID: some random crap about rev1 $ Line 2 - same file in revision 2: $ID: some other random crap about rev2 $ Line 2 got modified and think about it. Your diff will be something like @@ -1,2 +1,2 @@ $ID:$ -Line 2 +Line 2 got modified and the diff WON'T EVEN APPLY! What kind of diff is that? Would you call it perhaps "totally broken"? In other words, there's no way in hell you can make this work. You'll end up always having to edit the keywords parts of diffs to make them apply if they are part of the context. (This, btw, is something that a CVS person says "so what?" about. They're _used_ to having to do it. It's how you do merges in CVS. Really. How many people have actually *worked* with branches in CVS on any complex project with any nontrivial work happening on the branch? I have. I hated CVS for many reasons. Keywords was just a small small detail in that hate relationship, but it was one of them!) Linus - 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