Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)

On Fri, 28 Nov 2008, Junio C Hamano wrote:

"Shawn O. Pearce" [off-list ref] writes:

quoted

Johannes Schindelin [off-list ref] wrote:
...

quoted

In other words, unless there is more interest in that feature, enough to 
generate a well-understood design before a good implementation, I'd rather 
see this patch series dropped.

Ack.  I agree with every remark made by Dscho, and also want to cry "wolf".

I haven't had time to read the patch series.  Its big and intrusive
and I just don't need the feature.

Well, "me neither".  Although I personally think resisting changes until
it becomes absolutely necessary is a good discipline, we also need to
recognise that there is a chicken-and-egg problem.  When you have a
potentially useful feature, unless people actually try using it in the
field, you won't discover the drawbacks in either the design nor the
implementation, let alone any improvements.

I just looked over most of it (skipping the generic index extension 
portion). It looks to me like it's introducing an extra concept to avoid 
actually fixing maybe-bugs in the "assume unchanged" implementation 
when used with files that have been changed intentionally (with the user 
intending git to overlook this change). Sparse checkout is essentially a 
special case of this, where the user has changed the working directory 
radically (not populating it at all) and wants git to carry on as if this 
was not the case (with a certain amount of porcelain code to cause this to 
happen automatically).

If there's any need for this to be distinguished from "assume unchanged", 
I think it should be used with, not instead of, the CE_VALID bit; and it 
could probably use some bit in the stat info section, since we don't need 
stat info if we know by assumption that the entry is valid.

	-Daniel
*This .sig left intentionally blank*