Re: More precise tag following

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 27, 2007, 19:13 UTC
Message-ID: <Pine.LNX.4.63.0701272004250.22628@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <45BB87EB.7010200@fs.ei.tum.de>

Hi,

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

Show 9 quoted lines

> 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.

Show 6 quoted lines

> > 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?

Show 5 quoted lines

> > 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?

Show 6 quoted lines

> > 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