On 11/29/08, Daniel Barkalow <barkalow@xxxxxxxxxxxx> wrote: > On Fri, 28 Nov 2008, Junio C Hamano wrote: > > > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > > > > > Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > > ... > > >> 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). I chose to use another bit because I did not want to change the behaviour of CE_VALID bit: it assumes all files are present. > 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. Interesting. I'll think more about this. > -Daniel > *This .sig left intentionally blank* > > -- > 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 > -- Duy -- 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
