2012/2/6 Junio C Hamano <gitster@xxxxxxxxx>: > This is open source, and I wouldn't stop you from spending time on anything > that interests you. Well fun stuff is more interesting to do.. but I guess that's about it. More time cut down requires bigger changes that does not fit in a few hours of work. > But having said that, if you have extra Git time, I would still rather see > you spend it first on tying up loose ends of your topics in flight and > on helping others that touch parts that are related to areas that you have > already thought about, namely: > > (1) nd/commit-ignore-i-t-a, which I think should be marketted as fixing > an earlier UI mistake and presented with a clean migration path to > make the updated behaviour the default in the future; and Yeah, I was avoiding the deprecation procedure (plus providing a convincing argument to push it forward). Need to look up old emails.. > (2) the negative pathspec thing that resurfaced in disguise as Albert > Yale's "grep --exclude" series. This is pure headache. Can't avoid it forever, I guess. > *1* A possible approach might be to stuff unmodified trees in the index > without exploding them into its components, and as entries are modified, > lazily expand these "tree" entries, while ensuring the "unmodified" parts > remain unmodified by turning the files in the working tree read-only and > requiring the user to say "git edit" or "git open" or something before > starting to edit. But as I said, I consider this not an ultra-urgent > issue, so I haven't thought things through yet. A sparse index is something that may be achieved with narrow clone (or narrow checkout in full clone) because by nature we can't have full index in narrow clone. That may be the right way to go. -- 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