Re: Getting a commit sha1 from fast-import in a remote-helper

From: Mike Hommey <mh@glandium.org>
Date: Nov 18, 2014, 03:11 UTC
Message-ID: <20141118031147.GA15358@glandium.org>
In-Reply-To: <20141118025131.GH4336@google.com>

On Mon, Nov 17, 2014 at 06:51:31PM -0800, Jonathan Nieder wrote:

Show 20 quoted lines

> 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.

Show 13 quoted lines

> [...]
> >> 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