From: Karsten Blees <karsten.blees@gmail.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: "René Scharfe" <l.s.r@web.de>,
"Git Mailing List" <git@vger.kernel.org>,
"Junio C Hamano" <gitster@pobox.com>
Subject: Re: [PATCH] abspath.c: use PATH_MAX in real_path_internal()
Date: Sun, 20 Jul 2014 02:29:53 +0200 [thread overview]
Message-ID: <53CB0D81.1070404@gmail.com> (raw)
In-Reply-To: <CACsJy8D5X5svApB9edHK+1EaGi+q2ZRSOvyDYaDieVV2psgZPg@mail.gmail.com>
Am 18.07.2014 12:49, schrieb Duy Nguyen:
> can be used, else we fall back to chdir. I think there are only four
> places that follow this pattern, here, setup.c (.git discovery), git.c
> (restore_env) and unix-socket.c. Enough call sites to make it worth
> the effort?
>
real_path(): here we actually don't want to cd / cd back, we just do
this because getcwd reolves symlinks.
setup.c: AFAICT this sets up the work dir and stays there (no cd back).
git.c: Only does a 'preliminary' repo setup so that the alias mechanism
reads the correct config files. Then it reverts the setup if the
resulting git command doesn't need it. Perhaps it would be better (and
faster) to teach the alias code to read the right config file in the
first place?
unix-socket.c: This looks pretty broken. The cd / cd back logic is only
ever used if the socket path is too long. In this case, after cd'ing to
the parent directory of the socket, unix_stream_listen tries to unlink
the *original* socket path, instead of the remaining socket basename in
sockaddr_un.sun_path. I.e. the subsequent bind() will fail on second
invocation of the credential daemon.
next prev parent reply other threads:[~2014-07-20 0:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-17 12:45 [PATCH] abspath.c: use PATH_MAX in real_path_internal() Nguyễn Thái Ngọc Duy
2014-07-17 17:05 ` René Scharfe
2014-07-17 18:13 ` Junio C Hamano
2014-07-17 23:03 ` Karsten Blees
2014-07-18 10:49 ` Duy Nguyen
2014-07-18 15:08 ` René Scharfe
2014-07-19 12:51 ` Duy Nguyen
2014-07-20 0:29 ` Karsten Blees [this message]
2014-07-20 8:00 ` René Scharfe
2014-07-21 2:25 ` Jeff King
2014-07-18 11:32 ` René Scharfe
2014-07-19 23:55 ` Karsten Blees
2014-07-20 11:17 ` René Scharfe
2014-07-17 18:03 ` Junio C Hamano
2014-07-17 23:02 ` Karsten Blees
2014-07-17 23:03 ` Karsten Blees
2014-07-18 16:45 ` Junio C Hamano
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=53CB0D81.1070404@gmail.com \
--to=karsten.blees@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=l.s.r@web.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).