On 12/11/07, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > On Tue, 11 Dec 2007, Linus Torvalds wrote: > > > > We do that. The expense for git is that we don't do the revisions as a > > single file at all. We'll look through each commit, check whether the > > "gcc" directory changed, if it did, we'll go into it, and check whether > > the "ChangeLog" file changed - and if it did, we'll actually diff it > > against the previous version. > > And, btw: the diff is totally different from the xdelta we have, so even > if we have an already prepared nice xdelta between the two versions, we'll > end up re-generating the files in full, and then do a diff on the end > result. This is what SVN does as well. > > Of course, part of that is that git logically *never* works with deltas, > except in the actual code-paths that generate objects (or generate packs, > of course). So even if we had used a delta algorithm that would be > amenable to be turned into a diff directly, it would have been a layering > violation to actually do that. Right. SVN has the same problem. > > Other systems can sometimes just re-use their deltas to generate the > diffs and/or blame information. I dunno whether SVN does that. CVS does, > afaik. CVS does because it's delta is line based, so it's easy. You theroetically can generate blame info from SVN/GIT's block deltas, but you of course, have the problem GIT does, which is that the delta is not meant to represent the actual changes that occurred, but instead, the smallest way to reconstruct data x from data y. This only sometimes has any relation to how the file actually changed - 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
