Hi, On Mon, 8 Sep 2008, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > Steffen Prohaska <prohaska@xxxxxx> writes: > > > >> Apologies for proposing such large changes that late in the release > >> cycle. Maybe we want to postpone the series until 1.6.0.1 or even > >> 1.6.1. > > > > Well, from the cursory look, it does not seem to be 1.6.0.1 material, > > even though it is possible to fork a topic at 1.6.0 and use the > > changes in 'next', then 'master', and eventually to 'maint' to produce > > 1.6.0.X, if all of this hapapens before 1.6.1. > > > > I wouldn't mind at all if the binary distribution on Windows is based > > on "git.git plus port specific patchset that will eventually be sent > > upstream" like it used to be. In fact it might even be preferrable, > > as I won't be testing ports to that platform myself anyway. > > If the depth difference between /usr/libexec/git-cat-file and /bin/git > is the major source of this headache, I do not think it is unreasonable > for the mingw git port to use "gitexecdir=$(bindir)" layout by default. > After all, Windows users do not really care where bulk of things are, as > long as they see one single clickable icon on the desktop, don't they? I think the main point is that we could (finally!) adopt a saner default on Unix: instead of hardcoding an absolute exec path, a relative would do. So I'd like to see this supported for Linux... Ciao, Dscho -- 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
