git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git cat-file -e behavior

From
Jeff King <peff@peff.net>
Date
Feb 29, 2016, 12:36 UTC
Message-ID
<20160229123645.GA20754@sigill.intra.peff.net>
In-Reply-To
<56D436A2.4090202@cihar.com>
On Mon, Feb 29, 2016 at 01:16:34PM +0100, Michal Čihař wrote:
Show 11 quoted lines
> Dne 29.2.2016 v 12:44 Jeff King napsal(a):
> > It looks like it has been this way forever. The first thing we do with
> > the object is resolve its name to a sha1, and that's where the error you
> > see comes from. And then we actually check whether we have the object.
> > 
> > I think the intended use was to feed it a sha1 to see if it exists. Then
> > the name-resolution step is a noop.
> 
> I found this as best way to check whether file exists in branch.
> Checking git ls-tree output seems less error prone than checking return
> value of git cat-file -e...
I think the usual way to do that would be:
  git rev-parse --verify $branch:$path >/dev/null

which just resolves the name (not that what you are doing is wrong, I just think rev-parse is the way we usually do it in our scripts).

That _will_ write a message to stderr when the name doesn't resolve.
-Peff
Previous: Michal ČihařNext: Jeff King
Message 4 of 5 in “git cat-file -e behavior”
  1. Michal ČihařFeb 29, 2016
  2. Jeff KingFeb 29, 2016
  3. Michal ČihařFeb 29, 2016
  4. Jeff KingFeb 29, 2016
  5. Jeff KingFeb 29, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.