From: Junio C Hamano <junkio@cox.net>
To: Greg Louis <glouis@dynamicro.on.ca>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Redirect cd output to /dev/null, was: git-clone seems dead
Date: Mon, 12 Sep 2005 05:29:08 -0700 [thread overview]
Message-ID: <7vbr2yfp0r.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20050912105637.GA5290@athame.dynamicro.on.ca> (Greg Louis's message of "Mon, 12 Sep 2005 06:56:37 -0400")
Greg Louis <glouis@dynamicro.on.ca> writes:
> I could argue that it's a relatively harmless contribution to
> robustness of the git scripts, but if someone replied that total
> idiot-proofing isn't a worthwhile goal for a project of this sort, I
> wouldn't necessarily disagree.
I have been made aware of the CDPATH issue since Carl Baldwin
diagnosed it last week, but have not done anything about it
because I am ambivalent about what the right thing to do is.
We could:
(0) do nothing and let people shoot in the foot themselves.
(1) unset CDPATH silently while we run. Most conveniently done
by doing so at the beginning of git-setup-sh, and scripts
that do not use the setup script but still does "cd".
(2) detect CDPATH in the same places as (1), complain and die.
Among these, (1) would be naturally the approach of least
resistance. It would make things "just work" for everybody, and
I do not have to deal with bug reports from people with a broken
environment, nor have to waste time preaching why CDPATH as an
environment is bad.
That, however, would guard only me without helping the world.
Such a broken environment would still harm other scripts. In
that sense (2) would be a better approach -- the "complain and
die" step would make it explicit what we do not like about their
environments. But that would put me in the position of "CDPATH
considered harmful" preacher -- I do not want to waste time on
defending that position every time a misguided soul wants to
keep CDPATH in his environment for whatever reason. I may end
up even explaining the difference between plain shell variable
and environment variable depending on how misguided that soul is
X-<.
And unlike (1), it would be more baggage to carry around. It's
only difference between 1 line vs 3 to 4 lines of shell scripts,
but 1 line just to idiot proof feels far more attractive to me
than 4 lines that starts and commits me to a crusade I do not
particularly care about.
Yes, I do realize that I am contradicting myself when I say (1)
does not help the world but I do not particularly want to spend
time and effort on helping the world anyway. If I really wanted
to make the world a better place, I should do (2) and be
prepared to spend some time defending that position. Otherwise
I should just weasel out of the problem by doing (1), keep
silent about the issue, let other people who supply scripted
solution suffer and call it their problem.
I would probably end up doing (1), though.
next prev parent reply other threads:[~2005-09-12 12:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-11 18:13 git-clone seems dead Peter Eriksen
2005-09-11 19:04 ` Junio C Hamano
2005-09-11 22:04 ` Greg Louis
2005-09-11 23:01 ` [PATCH] Redirect cd output to /dev/null, was: " Greg Louis
2005-09-12 1:47 ` Junio C Hamano
2005-09-12 9:22 ` Peter Eriksen
2005-09-12 10:56 ` Greg Louis
2005-09-12 12:29 ` Junio C Hamano [this message]
2005-09-12 16:36 ` Greg Louis
2005-09-12 19:53 ` Junio C Hamano
2005-09-13 11:07 ` Greg Louis
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=7vbr2yfp0r.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
--cc=glouis@dynamicro.on.ca \
/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).