Re: More precise tag following

Hi,

On Sat, 27 Jan 2007, Simon 'corecode' Schubert wrote:

Johannes Schindelin wrote:

quoted

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.

quoted

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?

quoted

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?

quoted

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