On Fri, Dec 7, 2018 at 4:51 PM Steven Penny <svnpenn@xxxxxxxxx> wrote: > > On Fri, Dec 7, 2018 at 11:04 AM wrote: > > The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix() > > is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin > > in the same way as it is done in 'Git for Windows' in compat/mingw.[ch] > > > > Instead of duplicating the code, it is extracted into compat/mingw-cygwin.[ch] > > Some need for refactoring and cleanup came up in the review, they are adressed > > in a seperate commit. > > i have applied the 3 patches against current master, and my original test > passes, so looks good to me. > > however like Johannes i take issue with the naming. as he said "mingw-cygwin" > really isnt appropriate. ideally it would be "windows.h", but as that is > conspicuously in use, something like these: > > - pc-windows > - pc-win > - win > > i disagree with him on using "win32" - that doesnt really make sense, as > obviously you can compile 64-bit Git for Windows. if you wanted to go that route > you would want to use something like: > > - windows-api > - win-api > - winapi > > further - i disagree with the "DOS" moniker being used at all. DOS is a defunkt > operating system that i dont think Git has *ever* supported, so it doesnt make > sense to be referring to it this way. again, a more approriate name would be > something like "win_drive_prefix". You seem to want internal function and filenames to be based on the product or marketing names of currently targetted systems. I don't see why this is desirable; could you explain why it is? I admit that I seem to see things more from Dscho's angle. However, I know much less about Windows than either of you. Perhaps my best understanding of the situation might help, limited as it is: - Using currently targetted system names means future code churn -- we may have to rename functions and files for absolutely no useful gain, muddying the history, making it harder for developers to remember how to find things, etc., simply because an external party renamed their libraries or introduced a new product. - For people less familiar with windows, "windows-api/win-api/winapi" and "win_drive_prefix" may sound like something only available in newer systems, making them wonder if the file name or function name is referring to some new windows concept they are unfamiliar with - Mentioning an anchor point where the relevant concept originally targetted or where it came from (win32/path.c, dos_drive_prefix) avoids or greatly reduces both problems. I'm worried based on other emails in this thread that there is a fundamental difference in frame of reference leading to a misunderstanding about rationale for naming, and worse that folks might not even realize where the misunderstanding is coming from, attributing it to different motives rather than different frames of reference. If that's true, I hope this email can begin the process of clearing up the differences of understanding. If I'm wrong, then I apologize for the noise; just ignore me. Best wishes, Elijah
