From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff King Subject: Re: [PATCH 2/2] grep: use slash for path delimiter, not colon Date: Mon, 26 Aug 2013 17:13:20 -0400 Message-ID: <20130826211320.GA26417@sigill.intra.peff.net> References: <20130826195331.GA21051@sigill.intra.peff.net> <20130826195616.GB21074@sigill.intra.peff.net> <521BB6DA.5050807@kdbg.org> <20130826205215.GB23598@sigill.intra.peff.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Johannes Sixt , Phil Hord , "git@vger.kernel.org" , Junio C Hamano , Jonathan Nieder To: Phil Hord X-From: git-owner@vger.kernel.org Mon Aug 26 23:13:29 2013 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 1VE46L-0004Pv-34 for gcvg-git-2@plane.gmane.org; Mon, 26 Aug 2013 23:13:29 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752093Ab3HZVNZ (ORCPT ); Mon, 26 Aug 2013 17:13:25 -0400 Received: from cloud.peff.net ([50.56.180.127]:40067 "EHLO peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751743Ab3HZVNY (ORCPT ); Mon, 26 Aug 2013 17:13:24 -0400 Received: (qmail 32248 invoked by uid 102); 26 Aug 2013 21:13:24 -0000 Received: from c-71-63-4-13.hsd1.va.comcast.net (HELO sigill.intra.peff.net) (71.63.4.13) (smtp-auth username relayok, mechanism cram-md5) by peff.net (qpsmtpd/0.84) with ESMTPA; Mon, 26 Aug 2013 16:13:24 -0500 Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Mon, 26 Aug 2013 17:13:20 -0400 Content-Disposition: inline In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Mon, Aug 26, 2013 at 05:03:04PM -0400, Phil Hord wrote: > > $ git grep -l foo HEAD | head -1 > > HEAD:RelNotes/1.5.1.5.txt > > > > we still limit to the current directory, but the output does not note > > this (it should be "HEAD:./RelNotes/1.5.1.5.txt"). I think this bug is > > orthogonal to Phil's patch, though. > > Maybe not. My path completes the assumption that the L:R value > returned by grep is an object ref; but Junio still thought it wasn't. > I think this is another case where his view was correct. I certainly assumed it was, because it is in most cases it is. And something like "HEAD:RelNotes/1.5.1.5.txt" certainly _looks_ like one, and is generated by the current git. And what is the point of coming up with a file listing if the names you return do not actually exist? > There's more bad news on this front. > > $ cd Documentation > $ git grep -l foo HEAD .. | head -1 > HEAD:../.gitignore > > That's not a valid ref, either (though maybe it could be). Yes, though we seem to normalize paths already. So the other entries from that command are (in git.git): HEAD:../.mailmap HEAD:RelNotes/1.5.1.5.txt So we could either: 1. Prepend the current path before normalizing to yield: HEAD:.mailmap HEAD:Documentation/RelNotes/1.5.1.5.txt 2. Teach the get_sha1 path parser about "..", and prepend "./" when we are in a prefixed subdir. HEAD:./../.mailmap HEAD:./RelNotes/1.5.1.5.txt -Peff