David Kastrup <dak@xxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Having made it sound so easy, here are the issues I would expect >> to be nontrivial (but probably not rocket surgery either). >> ... > This would seem to imply that the index does not need to be > upwards-compatible: simplifying the code means that old indexes won't > be treated all too well. I did not imply any such thing, by the way. These are off the top of my head technical issues and there probably are more, but I limited the list to technical side of the things. You of course have social side to take care of. If you are breaking everybody else's index, you would need to tell everybody: "I am sorry but if you upgrade your git to this version that does what I want, you have to nuke your index and start over, so commit all changes first, and then update the git. Sorry for causing you a minor inconvenience". Everybody at this point involves (obviously) the kernel folks, wine, x.org, among many others. I suspect your saying that to them is probably not good enough for them to forgive the minor inconveniences, which means you need to convince _me_ to join you in defending, in the release notes, that this is a feature worth having even though there is a minor inconvenience to redo everybody's index files. Which I suspect is quite unlikely to happen at this moment, though... A much less troublesome approach might be to do things differently from what I outlined, to keep the index compatible as long as it does not contain an empty directory, which is what we did for subprojects support. - 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
