Hi, On Sat, 27 Jan 2007, Simon 'corecode' Schubert wrote: > Johannes Schindelin wrote: > > > Many people don't use or even need blame. And what you want to > > introduce would affect them, too. > > Many people do not use colored diffs. Introducing colored diff support > affects them, too. In which way? Additional command line switches, for > example. I don't think that's a big deal, and neither is a reverse map > to create object-level DAGs. Do colored diffs need additional data? No. There's the principal difference between rev-pathspec-speed-up and colored-diffs. > Please don't take the mentioning of hg as an attack on git. You don't > have to shoot back. I did not take it as an attack on git! If it sounded like that, sorry. (Side note: If there is _any_ feature in other versioning systems I would like to have in git, I'll try to implement it. If there is a VCS that is better than git, and which is free, I'll use it. Sorry, but that's the way it is.) I only tried to make it clear why we do not do things as Mercurial does it (in this particular case at least), and why I think that git's way is better. > > Rather, calculate the information you need from the existing data, and > > if you can reuse it, store it locally. _That_ is flexibility. > > Of course this is flexibility. But this also means that every consumer > has to do this for every repo. Wouldn't it be nice to have it done one > time and then stored in a pack? So you want to store it in a pack, fetchable? > > It also gives me a warm fuzzy feeling that no bogus "auxillary > > information" can be introduced by fetching from somewhere else. (It > > does not matter if intended or unintended.) > > I agree on that. So you agree we should _not_ store it in a pack, fetchable? > > And if something is wrong with that "auxillary information", it can be > > regenerated correctly, without touching the real data -- the commit > > ancestry. > > Yes, it always can be regenerated. I never said it should be made part > of the core structure. So, if you _do_ have it in a pack, fetchable, what happens if you regenerated it locally, fixing a flaw, but then fetch it from somewhere else, where the flaw possibly still exists, what do you do? Ciao, Dscho - 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