All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Dana How" <danahow@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Jakub Narebski" <jnareb@gmail.com>,
	"Alex Riesen" <raa.lkml@gmail.com>,
	git@vger.kernel.org,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Subject: Re: log/show: relative pathnames do not work in rev:path
Date: Wed, 19 Dec 2007 12:45:16 -0800	[thread overview]
Message-ID: <7v8x3qv2g3.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <56b7f5510712181430w798d4a65x20a24f061c5d0eb6@mail.gmail.com> (Dana How's message of "Tue, 18 Dec 2007 14:30:40 -0800")

"Dana How" <danahow@gmail.com> writes:

> How about this:
> <tree-ish>:./path -> NEW: relative

I think making "<tree>:./" mean "replace ./ with the current prefix and
retry the usual expansion" is relatively confusion free.  You have to
work hard to confuse yourself:

	d=$(git rev-parse --verify HEAD:Documentation)
        git rev-parse "$d":./howto ;# would not work
	cd Documentation && git rev-parse "$d":./howto ;# would work

> <tree-ish>:../path -> NEW: relative

I would rather avoid up (../) processing if we can, but making "<tree>:"
immediately followed by 1 or more "../" mean "take the current prefix,
strip away the same number of trailing directory components as we have
"../" there, and tuck the remainder in front of the path before trying
the usual expansion" would be a natural and relatively confusion free
extension of the above.  I think I can live with that, too.

> <tree-ish>:?pattern -> NEW: same as next (current :/ )

I'd prefer keeping :? (or some other unlikely-in-path letter other than
'?') as a special extension introducer character, i.e. leaving the door
open to:

	<tree>:?(magic)parameter

whose semantics is to be defined later, depending on "magic".

Similarly, we could do the same for

	:?(magic)parameter

> <tree-ish>:/pattern -> unchanged (sha1_name_oneline IIRC)

I do not think this is oneline.  "<commit>:/pattern" could be a natural
extension to the current ":/pattern" that instructs "dig from only this
commit, not all refs, and find a commit with the oneline," but I do not
think it is a good idea.  It is too similar to "locate this tree entry
from the given tree" syntax.

> <tree-ish>:path -> unchanged: absolute

Absolutely ;-)

  parent reply	other threads:[~2007-12-19 20:46 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-18 17:33 log/show: relative pathnames do not work in rev:path Alex Riesen
2007-12-18 17:50 ` Jakub Narebski
2007-12-18 20:46   ` Alex Riesen
2007-12-18 20:47     ` [PATCH] Simple support for tree entry specification with relative pathnames Alex Riesen
2007-12-18 20:49       ` [PATCH] Introduce pathexpand: syntax-level chdir into the given cwd Alex Riesen
2007-12-18 20:52         ` [PATCH] Use pathexpand to preparse the relative pathnames in blob references Alex Riesen
2007-12-18 21:06           ` Dana How
2007-12-19 14:37           ` Jeff King
2007-12-18 21:03       ` [PATCH] Simple support for tree entry specification with relative pathnames Dana How
2007-12-18 21:17         ` Alex Riesen
     [not found]           ` <56b7f5510712181539g27bd4fc9y632ebe74d91b8e82@mail.gmail.com>
2007-12-19  7:36             ` Alex Riesen
2007-12-18 21:24     ` log/show: relative pathnames do not work in rev:path Jakub Narebski
2007-12-18 21:53       ` Linus Torvalds
2007-12-18 22:08         ` Dana How
2007-12-18 22:29           ` Alex Riesen
2007-12-18 22:20         ` Junio C Hamano
2007-12-18 22:30           ` Dana How
2007-12-18 23:02             ` Johannes Schindelin
2007-12-19 20:45             ` Junio C Hamano [this message]
2007-12-18 22:20       ` Alex Riesen
2007-12-18 22:43         ` Johannes Schindelin
2007-12-18 23:03           ` Dana How
2007-12-18 23:26             ` Johannes Schindelin
2007-12-19  1:16             ` Linus Torvalds
2007-12-19  1:52               ` Dana How
2007-12-19  7:42                 ` Alex Riesen
2007-12-19 11:23                 ` Jakub Narebski
2007-12-19 17:21                   ` Dana How
2007-12-19 18:47                     ` Jakub Narebski
2007-12-19 13:40                 ` [PATCH v0] sha1_name: grok <revision>:./<relative-path> Johannes Schindelin
2007-12-19 15:05                   ` Jeff King
2007-12-19 17:40                     ` Dana How
2007-12-19 18:09                       ` Alex Riesen
2007-12-20  1:07                   ` Junio C Hamano
2007-12-20 10:51                     ` Johannes Schindelin
2007-12-21 14:17                   ` Nguyen Thai Ngoc Duy
2007-12-21 17:50                     ` Junio C Hamano
2007-12-21 20:15                       ` Nguyen Thai Ngoc Duy
2007-12-22 14:33                     ` Johannes Schindelin
2007-12-18 23:11           ` log/show: relative pathnames do not work in rev:path Jakub Narebski
2007-12-18 23:15             ` Dana How
2007-12-18 23:18           ` Junio C Hamano
2007-12-18 23:05         ` Jakub Narebski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v8x3qv2g3.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=danahow@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    --cc=raa.lkml@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.