On Tue, Jan 5, 2010 at 1:39 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Avery Pennarun <apenwarr@xxxxxxxxx> writes: >> On Tue, Jan 5, 2010 at 12:40 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> Then we don't even have to add any specific support for "google-chrome" or >>> anything that takes "$command $path..." and opens the documents. >>> >>> Is there a downside in this approach? >> >> If someone has another firefox-derived browser installed with a >> different name and tries to use it, this default wouldn't do the right >> "firefoxy" thing, and would instead fail strangely. On the other >> hand, right now it'll fail anyway, just not strangely. > > You probably didn't notice/understand why I singled out w3m/links/open and > excluded firefox from the set. There is no question that the ones that > need custom command line need custom support. But to support a new > browser that takes a bog standard "command then args" command line, there > is no reason to add cruft, every time somebody comes up with a new browser. Yes, I'm probably missing something, that would be normal :) My point is that, given a random browser name, you don't know whether it's an easy one *or* if it needs to work more like firefox. The current behaviour will barf right away (I think) because it doesn't know. If it instead had a default case that just assumed non-firefox behaviour, then it would fail *strangely* (instead of predictably) on browsers that needed special workarounds, such as an as-yet-unknown firefox derivative. Maybe this isn't important though. Avery -- 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