Re: [RFC PATCH] git-sh-setup: Use "cd" option, not /bin/pwd, for symlinked work tree

From: Marcel M. Cary <marcel@oak.homeunix.org>
Date: Feb 8, 2009, 18:11 UTC
Message-ID: <498F2049.9030608@oak.homeunix.org>
In-Reply-To: <alpine.DEB.1.00.0902071324230.10279@pacific.mpi-cbg.de>

Johannes Schindelin wrote:

Show 6 quoted lines

> On Fri, 6 Feb 2009, Marcel M. Cary wrote:
>> While the "-P" option may be slightly less commonly supported than
>> /bin/pwd,
>
> Does this not suggest that your patch should at least fall back to
> using /bin/pwd when it was detected that "cd -P" does not work?

Having the "cd -P" strategy fall back to /bin/pwd negates most of the value I saw in using the simpler strategy.

I haven't found cases where "cd -P" is more correct. Are there other reasons to bother with "cd -P" at all? Maybe performance: "cd -P" would save a fork, which seems to make it ~10x faster. Dropping buffer caches doesn't seem to widen or narrow the gap, so I don't think the filesystem access is much different, performance-wise. But I don't expect this "cd" to be a performance bottleneck; most scripts that do something repetitive can just start off in the work tree root to avoid the issue.

Falling back to /bin/pwd would help compatibility if it were easy to detect when "cd -P" failed. But since its failure is hypothetical for me at this point -- I don't know of an environment where it fails -- I'm not sure whether to expect it to fail with non-zero exit status or by silently ignoring the "-P". And to handle the cases of silently ignoring the "-P" I'd guess cd_to_toplevel would have to run /bin/pwd just to check that it ended up in the right place, which seems counterproductive to me. Do you think it would be reasonable to just assume "cd -P" will exit non-zero if "cd" doesn't understand "-P", send its stderr to /dev/null, and try again using /bin/pwd?

Marcel