Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. -- 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
