All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC 4/6] git-check-attr: Normalize paths
Date: Thu, 04 Aug 2011 05:32:09 +0200	[thread overview]
Message-ID: <4E3A12B9.1010800@alum.mit.edu> (raw)
In-Reply-To: <7v4o1zg20r.fsf@alter.siamese.dyndns.org>

On 08/02/2011 07:24 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> 1. I'm not sure whether it is correct to fix this problem at the level
>>    of git-check-attr, or whether the fix belongs in the API layer.
>>    What is the convention for API functions?  Do they typically take
>>    path names relative to the CWD or relative to the working tree
>>    root, or ...?
> 
> I think passing down "prefix" (i.e. where your $(cwd) was relative to the
> root level of the working tree) and the user-supplied "pathspec" (which
> typically is relative to that original $(cwd)) is the canonical approach.
> The very original git worked only at the root level of the working tree,
> with paths specified relative to the root level of the tree, so many code
> do:
> 
> 	- find out the root of the working tree;
>         - note where the $(cwd) was in "prefix";
>         - chdir to the root of the working tree;
> 	- prepend the "prefix" to user supplied pathspec;
>         - forget all the complexity and work on the whole tree.
> 
> Then the "prefix" gets stripped away from the beginning of the paths when
> reporting.
> 
> Your patch from a cursory look seems to follow that pattern, which is
> good.

Thanks for the explanation.

Yes, my code follows the pattern, except that in this case it is
unnecessary to chdir to the root of the working tree.

All this chdiring is going to be a nightmare for the libification of
git, since the cwd is a program-wide global variable with implicit
side-effects on almost any code that deals with the filesystem.  It is
obviously not permissible for a library to change directories (not even
temporarily, if the library is intended to be used in a multithreaded
application).  But that is a topic for another day.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

  reply	other threads:[~2011-08-04  3:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-28 10:36 [RFC 0/6] git-check-attr should work for relative paths Michael Haggerty
2011-07-28 10:37 ` [RFC 1/6] git-check-attr: test that no output is written to stderr Michael Haggerty
2011-07-28 10:37 ` [RFC 2/6] git-check-attr: Demonstrate problems with unnormalized paths Michael Haggerty
2011-07-28 10:37 ` [RFC 3/6] git-check-attr: Demonstrate problems with relative paths Michael Haggerty
2011-07-28 10:37 ` [RFC 4/6] git-check-attr: Normalize paths Michael Haggerty
2011-08-02 17:24   ` Junio C Hamano
2011-08-04  3:32     ` Michael Haggerty [this message]
2011-08-04 17:05       ` Junio C Hamano
2011-08-05  6:24         ` Michael Haggerty
2011-08-05 15:02           ` Junio C Hamano
2011-08-07  4:32             ` Michael Haggerty
2011-07-28 10:37 ` [RFC 5/6] test-path-utils: Add subcommand "absolute_path" Michael Haggerty
2011-07-28 10:37 ` [RFC 6/6] test-path-utils: Add subcommand "prefix_path" Michael Haggerty
2011-08-02 22:02 ` [RFC 0/6] git-check-attr should work for relative paths Junio C Hamano
2011-08-04  3:35   ` Michael Haggerty

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=4E3A12B9.1010800@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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.