From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff King Subject: Re: RFC: git cat-file --follow-symlinks? Date: Wed, 29 Apr 2015 20:37:51 -0400 Message-ID: <20150430003750.GA4258@peff.net> References: <1430341032.14907.9.camel@ubuntu> <1430343059.14907.18.camel@ubuntu> <20150429214817.GA2725@peff.net> <1430346576.14907.40.camel@ubuntu> <20150429231150.GB3887@peff.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Junio C Hamano , git mailing list To: David Turner X-From: git-owner@vger.kernel.org Thu Apr 30 02:38:01 2015 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YncUJ-00060P-5q for gcvg-git-2@plane.gmane.org; Thu, 30 Apr 2015 02:37:59 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751921AbbD3Ahy (ORCPT ); Wed, 29 Apr 2015 20:37:54 -0400 Received: from cloud.peff.net ([50.56.180.127]:51969 "HELO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751160AbbD3Ahy (ORCPT ); Wed, 29 Apr 2015 20:37:54 -0400 Received: (qmail 30547 invoked by uid 102); 30 Apr 2015 00:37:53 -0000 Received: from Unknown (HELO peff.net) (10.0.1.1) by cloud.peff.net (qpsmtpd/0.84) with SMTP; Wed, 29 Apr 2015 19:37:53 -0500 Received: (qmail 32389 invoked by uid 107); 30 Apr 2015 00:38:23 -0000 Received: from sigill.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.7) by peff.net (qpsmtpd/0.84) with SMTP; Wed, 29 Apr 2015 20:38:23 -0400 Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Wed, 29 Apr 2015 20:37:51 -0400 Content-Disposition: inline In-Reply-To: <20150429231150.GB3887@peff.net> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Wed, Apr 29, 2015 at 07:11:50PM -0400, Jeff King wrote: > Yeah, I agree if you let git punt on leaving the filesystem, most of the > complicated problems go away. It still feels a bit more magical than I > expect out of cat-file, and there are still corner cases (e.g., do we do > cycle detection? Or just have a limit to the recursion depth?) I was pondering the "magical" above. I think what bugs me is that it seems like a feature that is implemented as part of one random bit of plumbing, but not available elsewhere. Conceptually, this is like peeling object names. You may give a tag name, but if you ask for a tree commit we will peel the tag to a commit, and the commit to a tree. This is sort of the same thing; you give a path within a tree, and we will peel until we hit a "real" non-symlink object. I don't know what the syntax would look like. To match "foo^{tree}" it would be something like: HEAD:foo/bar^{resolve} or something like that. Except that it is a bad idea to allow "^{}" syntax on the right-hand side of a colon, as it is ambiguous with filenames that contain "^{resolve}". So it would have to look something like: HEAD^{resolve}:foo/bar which is a _little_ weird, but actually kind of makes sense. The "resolve" operation inherently is not just about the filename, but about uses HEAD^{tree} as the root context. So I dunno. This pushes the resolving logic even _lower_ in the stack than it would be in cat-file. So why do I like it more? Cognitive dissonance? I guess I the appeal to me is that it: 1. Makes the concept available more generally (you can "rev-parse" it, you can "git show" it, etc). It also lets you _name_ the object in question, so you can ask for other things besides it contents (like its name, its type, etc). 2. Positions it alongside other peeling name-resolution functions. Thoughts? -Peff