From: "Carlos Martín Nieto" <cmn@elego.de>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: git@vger.kernel.org, Nguyen Thai Ngoc Duy <pclouds@gmail.com>,
Junio C Hamano <gitster@pobox.com>,
Brian Gernhardt <benji@silverinsanity.com>
Subject: Re: [PATCH 2-3/3] Name make_*_path functions more accurately
Date: Wed, 16 Mar 2011 19:17:44 +0100 [thread overview]
Message-ID: <1300299469.3995.10.camel@centaur> (raw)
In-Reply-To: <4D80EC57.4050704@drmicha.warpmail.net>
On Wed, 2011-03-16 at 17:59 +0100, Michael J Gruber wrote:
> Carlos Martín Nieto venit, vidit, dixit 16.03.2011 17:51:
>>[...]
> > -const char *make_nonrelative_path(const char *path)
> > +/*
> > + * Use this to get an absolute path from a relative one. If you want
> > + * to resolve links, you should use real_path.
> > + *
> > + * If the path is already absolute, then return path. As the user is
> > + * never meant to free the return value, we're safe.
> > + */
> > +const char *absolute_path(const char *path)
> > {
> > static char buf[PATH_MAX + 1];
> >
> > if (is_absolute_path(path)) {
> > - if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
> > + if (strlen(path) >= PATH_MAX)
> > die("Too long path: %.*s", 60, path);
> > + else
> > + return path;
> > } else {
> > size_t len;
> > const char *fmt;
>
> This is not simply a renaming change that you're sneaking in here. What
> is it about?
Gah, I've been staring at this patch too long. This is related another
thread where Junio said it'd be a good idea to change the semantics so
we centralise checking wether we already have an absolute path. See
http://thread.gmane.org/gmane.comp.version-control.git/169012/focus=169063 (Message-ID: <7vpqptb976.fsf@alter.siamese.dyndns.org>).
>>[...]
> > diff --git a/dir.c b/dir.c
> > index 570b651..5a9372a 100644
> > --- a/dir.c
> > +++ b/dir.c
> > @@ -1023,8 +1023,8 @@ char *get_relative_cwd(char *buffer, int size, const char *dir)
> > if (!getcwd(buffer, size))
> > die_errno("can't find the current directory");
> >
> > - if (!is_absolute_path(dir))
> > - dir = make_absolute_path(dir);
> > + /* getcwd resolves links and gives us the real path */
> > + dir = real_path(dir);
>
> Why remove the check? Again, this is not just renaming.
Semantics change. Same as above. The one below (snipped) is the same.
>>[...]
> I think you should strictly separate the renaming issue from other
> patches (and describe/motivate the latter). It's fine to have a large
> patch with mechanical changes (renaming) if you stick to just those.
Unfortunately I introduced some modifications trying to reduce the
number of times we call make_absolute_path/real_path and they snuck in.
Sorry.
cmn
next prev parent reply other threads:[~2011-03-16 18:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-16 16:51 [PATCH 2-3/3] Name make_*_path functions more accurately Carlos Martín Nieto
2011-03-16 16:59 ` Michael J Gruber
2011-03-16 18:17 ` Carlos Martín Nieto [this message]
2011-03-16 20:48 ` Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2011-03-16 16:06 [PATCH 0/3] Rename make_*_path with clearer names Carlos Martín Nieto
2011-03-16 16:52 ` [PATCH 2-3/3] Name make_*_path functions more accurately Carlos Martín Nieto
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=1300299469.3995.10.camel@centaur \
--to=cmn@elego.de \
--cc=benji@silverinsanity.com \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.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.