From: Dana How Date: Wed, 19 Dec 2007 17:40:04 GMT Subject: Re: [PATCH v0] sha1_name: grok :./ Message-ID: <56b7f5510712190940g2a377f4tfe3ca897561ed446@mail.gmail.com> In-Reply-To: <20071219150510.GB13942@coredump.intra.peff.net> On Dec 19, 2007 7:05 AM, Jeff King wrote: > On Wed, Dec 19, 2007 at 01:40:27PM +0000, Johannes Schindelin wrote: > > When you are in a deeply-nested directory structure, and just want > > to reference a blob in a past revision, it can be pretty slow to > > type out "HEAD~29:/bla/blub/.../that-file". > > > > This patch makes "HEAD~29:./that-file" substitute the current prefix > > for "./". If there is not working directory, the prefix is empty. > > I think this is definitely the right approach. Here's a (possibly > insane) alternative. Revert the change in get_sha1_with_mode and detect > "./" in get_tree_entry: > > [..] > > This means that the directory '.' becomes a token replacement for "my > current path" in tree paths. So if you are in "foo/bar", and you are > looking at a distance commit where the same content was in > "baz/foo/bar", you can do: > > git show distant:baz/./file > > This is probably insane because: > - this is a fairly unlikely use case > - get_tree_entry gets called in a lot of places, and I have no idea if > there will be some crazy fallouts. > > So it is probably not worth pursuing, but maybe somebody else can think > of a good use. For me, I was only interested in the recognition of ./ at the beginning of a path just after : (causing a cwd suffix to be inserted there). If there were additional /./ or /../ patterns in the result, I think it would be more useful (e.g. for script writers who forgot to run their file arguments thru something like "readlink -f") for them to be squashed out (e.g. in Perl: s#/(\./)+#/#g; s#/([^/]*[^./][^/]*/\.\./)+#/#g; ). But this is something that could be added later if desired to the interpretation of all paths, and so seems like a different issue. Thanks, -- Dana L. How danahow@gmail.com +1 650 804 5991 cell