Re: Should we discuss Windows-related changes on

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Fri, 11 Jul 2008, Linus Torvalds wrote:
>
>>  - It may well be good to explain to the _real_ git people (eg me) what 
>>    the problems in Windows land are, so that we get a first-hand view 
>>    into hell, and can maybe take it into account when we make changes 
>>    for other things.
>
> Wow.  I did not think that you were a masochist.

It is not being masochist, but being practical by trying to know what to
avoid in advance.

>> IOW, I think that since 1.6.0 is supposed to have native support for 
>> windows, we should have patches discussed on the regular git list. The 
>> ghetto that is windows can be useful for _user_ discussions, where a lot 
>> of the core git people simply cannot help. But having development 
>> discussions there is bad, I think.
>
> We do have development discussions there that do not belong to git@vger.  

Hannes did a great job with help from msysGit people to contain platform
specific stuff in compat/ layer.  A good rule of thumb to decide what not
to talk about here is:

 - If it is purely about implementation inside compat/ layer, such as
   creating spawn() using Windows specific API, it is probably better done
   on the msysGit list, where presumably more people whose has expertise
   on the particular platform would hang around;

 - If it is about "I downloaded msysgit prepackaged binary and this and
   that does not work as I expect, I haven't bothered trying to build it
   from source on POSIX systems and see if it is broken in the upstream",
   the RFH does not belong here but platform specific forum.  This applies
   not just to Windows but to various distro binary distributions on Linux
   as well.

On the other hand, even if it is related to porting to Windows, discussing
what the compat/ abstraction should look like is very relevant to this
list.

For example, I like is_absolute_path() abstraction you and Hannes pushed
for, but I have a slight distaste against has_dos_drive_prefix().  Some
uses of that macro is about telling if a string is a local file pathname
(e.g. connect()), and some other uses of that macro is about the fact that
on Windows you cannot necessarily make one path relative to another but
our code largely assume that any path can be made relative to any other
path (i.e. on traditional UNIX without "//", you can always make a path
relative by prefixing enough number of "../" to go up, even to root if
needed, but you cannot make C:\foo relative to D:\bar).  We may be able to
find a better abstraction than what has_dos_drive_prefix() offers, and I
think that discussion belongs to here.

Another example that has already happened was our move away from direct
use of fork/exec but abstracting it out to run_command() layer.  This
would not have settled in a shape usable by both Windows and POSIX if
people from both camps did not participate in the design and review.