Re: [PATCH v0] sha1_name: grok <revision>:./<relative-path>

["Dana How" <danahow@gmail.com>]

On Dec 19, 2007 7:05 AM, Jeff King <peff@peff.net> 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