On 8/17/08, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > "Nguyen Thai Ngoc Duy" <pclouds@xxxxxxxxx> writes: > > > ... > > >> The problem is "narrow rules" may change over time in a way that git > >> may handle it wrong. Assume that you have a directory with two files: > >> a and b. You first narrow checkout a (which would save the rule > >> "checkout a"). Then you do "git checkout b". When you update HEAD, > >> what should happen? > > > > I'd expect that this sequence: > > > ... > > > you can record list of pathspecs (with positive and negative) to implement > > that semantics, no? > > By the way, I was just mentioning the index extension area as a means to > store the rules if _you wanted to_. I do not insist you to actually store > the rules, and in fact, I do not know if it is even a good idea to do so. I was more worried about those rules getting out of control because git-checkout is not the only command that can change narrow rules. After enough commands, the rules can become a mess that you don't even want to look at them. I don't do negative rules now, but yes that's possible. > > Ok. We would need to use an extra bit for this. > > > > The bit 0x4000 is the last one available, so we would want to use it as > > "this index entry uses more bits than the traditional format" bit, and > > define a backward incompatible on-disk index entry format to actually > > record CE_NO_CHECKOUT and other flags we will invent in the future. > > > > Perhaps ondisk_cache_entry structure will have an extra "unsigned int > > flags2" after "flags" when that bit is on, and we can have 31 more bits in > > flags2, with the highest bit of flags2 signalling the presense of flags3 > > word in the future, or something like that. > > > It might make sense to do this first as a futureproof, if we really want > to go this route. We can ensure that an index that does use the new flag > bits won't be misinterpreted by older git. The patch is fine. Still we need to do something to prevent older git from using new index format. -- 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
