On Thu, 12 Jun 2008, Stephen R. van den Berg wrote: > > As I understood it from the few shreds of documentation that actually > mention the grafts file, the grafts file is *not* being cloned. > Therefore, my assumption was that cloning a repository that has a grafts > file gives an identical result to cloning the same repository *without* > the grafts file present. That would probably be the right behaviour, but no - all our commit walkers honor the grafts file. Including the ones used for creating pack-files and thus a clone. > As I understand it now, the cloning process actually peeks at the grafts > file while cloning, and then doesn't copy it. This results in a rather > confusingly corrupt clone. Yes. The grafts-file was a mistake, but it's just barely useful to some people that it's stayed alive. Sadly, those "some people" don't tend to care enough about the problems it can cause. > I suggest two things: > a. That during the cloning process, the grafts file is completely > disregarded in any case at first. Yes. And (a'): git-fsck and repacking should just consider it to be an _additional_ source of parenthood rather than a _replacement_ source. > b. Preferably the grafts file is copied as well (after cloning). I > never really understood why the file is not being copied in the first > place (anyone care to explain that?). The grafts file isn't part of the object stream and refs, and clones (and fetches) very much just copy the object database. Linus -- 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
