On Mon, Feb 7, 2011 at 7:18 PM, Ilari Liusvaara <ilari.liusvaara@xxxxxxxxxxx> wrote: > On Mon, Feb 07, 2011 at 04:57:13PM +0700, Nguyen Thai Ngoc Duy wrote: >> >> Perhaps it's not a good approach after all. What I wanted was to make >> pre-1.8.0 tolerate empty trees created by 1.8.0. Perhaps it's better >> to just let pre-1.8.0 refuse to work with empty trees, forcing users >> to upgrade to 1.8.0? >> >> The (untested) patch below would make git refuse to create an index >> from a tree that contains empty trees. Hmm? > > Remember, many distros ship with old versions of Git. Debian stable > is now at 1.7.2.3 (Squeeze became Debian 6.0) and it'll take years > before next release. What about these? Waiting a few years is my best bet :P Really I don't figure out any other way for migration. New empty trees would end up in repository and affect all connected clients regardless version. > Making previous versions refuse to work with empty trees isn't exactly > trivial, as the tree parser seems to be written to be extremely > liberal on what it accepts. The repository _can_ contain empty trees. The main problem is index not supporting empty trees. I only prevent index being used. If users create new commits (including empty trees) with mktree and commit-tree, they can also checkout without index using ls-tree and cat-file. -- 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