Johannes Schindelin wrote: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
