> It's hard to make out what do you mean, the patch description is much > clearer, paradoxically. It is hard to explain such a strange behaviour with a description that is both short and generic enough... But I agree with you. I just got bitten by this and I thought it was important enough to be specified. > Also, this in fact holds for the root tree > instead of the parent tree, and the behaviour changes from "weird" to > "simply broken" when you try to list a tree object that is _not_ the > root project tree from within a subdirectory: > > git$ git ls-tree HEAD Documentation > 040000 tree 066c25e86a44d4c7bde2d3e9b91e6891d752efa1 Documentation > git/Documentation$ git ls-tree 066c25e86a44d4c7bde2d3e9b91e6891d752efa1 > git/Documentation$ > > I think that ls-tree simply shouldn't auto-fill its pathspec based on > current prefix in case no pathspec was supplied. Patch to follow. I also thought this behaviour was broken. But I didn't want to patch it because I was afraid of breaking things that would rely on it, despite it seems unexpected enough not to be used... -- 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
