On Mon, Nov 17, 2014 at 06:51:31PM -0800, Jonathan Nieder wrote: > Mike Hommey wrote: > > On Mon, Nov 17, 2014 at 05:40:28PM -0800, Jonathan Nieder wrote: > > >> How did you get that "Not a blob" message? > > > > When trying to *create* a tree with a commit in it, so instead of giving > > the mark for a blob to a filemodify command, giving a mark for a commit. > > That is what fails with "Not a blob". > > Ah, I see what you were trying now. It's complaining that the data > and mode don't match up. See <mode> under 'filemodify' in the manual. > > Something like > > M 160000 :1 mycommit > > should work fine, though that's a pretty ugly workaround for the > inability to do > > ls :1
Actually, for my use, that ugly workaround actually improves things for me, avoiding to use blobs in some of the stuff I want to store :) How did I miss that? Thanks a lot for the enlightenment. > [...] > >> I think a good fix would be to teach parse_ls a mode with no <path> > >> parameter. Something like this (untested; needs cleanup and tests): > > > > This would make both your commands output the same thing, right? It > > wouldn't help my case :) > > It's easily possible my patch has a typo somewhere, but the expected > output format would be > > commit 6066a7eac4b2bcdb86971783b583e4e408b32e81 > > That wouldn't help? Oh, so `ls <dataref>` would print out what <dataref> is? That would definitely help, although with the trick above, I probably wouldn't actually need it anymore. Mike -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
