Re: [PATCH 0/7] prefix discovery at runtime (on Windows)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux