git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Elijah Newren <newren@gmail.com>
To: svnpenn@gmail.com
Cc: "Torsten Bögershausen" <tboegi@web.de>,
	"Git Mailing List" <git@vger.kernel.org>
Subject: Re: [PATCH v2 1/3] git clone <url> C:\cygwin\home\USER\repo' is working (again)
Date: Tue, 11 Dec 2018 19:47:40 -0800	[thread overview]
Message-ID: <CABPp-BHqJ_Dqpi-N-GVu9difvh-SnD1SZ2-SqaG0ctu5fBX-Tw@mail.gmail.com> (raw)
In-Reply-To: <CAAXzdLVTjCVDmBik-j9B_Z_2wgSj=_6baqmjmGEGBFOsjkyOsw@mail.gmail.com>

On Fri, Dec 7, 2018 at 4:51 PM Steven Penny <svnpenn@gmail.com> 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

  parent reply	other threads:[~2018-12-12  3:47 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-18 15:21 Cygwin Git with Windows paths Steven Penny
2018-11-18 15:41 ` Torsten Bögershausen
2018-11-18 16:23   ` Steven Penny
2018-11-18 17:15     ` Torsten Bögershausen
2018-11-18 17:34       ` Steven Penny
2018-11-18 18:28         ` Torsten Bögershausen
2018-11-18 19:00           ` Steven Penny
2018-11-19  0:06       ` Junio C Hamano
2018-11-19  2:11         ` Randall S. Becker
2018-11-19  3:33           ` Junio C Hamano
2018-11-19  5:20             ` Torsten Bögershausen
2018-11-20  0:17               ` Steven Penny
2018-11-20 10:36                 ` Torsten Bögershausen
2018-11-20 12:51                   ` Steven Penny
2018-11-19 12:22             ` Randall S. Becker
2018-11-26 17:32 ` [PATCH v1/RFC 1/1] 'git clone <url> C:\cygwin\home\USER\repo' is working (again) tboegi
2018-11-27  0:35   ` Steven Penny
2018-11-27  1:16   ` Junio C Hamano
2018-11-27  2:49     ` Steven Penny
2018-11-27  5:23       ` Junio C Hamano
2018-11-27  6:20         ` Steven Penny
2018-11-27 12:55         ` Johannes Schindelin
2018-11-28  4:10           ` Junio C Hamano
2018-11-28  5:55             ` J.H. van de Water
2018-11-28  8:46               ` Johannes Schindelin
2018-11-28  9:01                 ` Houder
2018-11-28  9:35                   ` Johannes Schindelin
2018-11-27 20:10     ` Achim Gratz
2018-11-27 12:49   ` Johannes Schindelin
2018-11-28  4:12     ` Junio C Hamano
2018-11-27 20:05   ` Achim Gratz
2018-12-07 17:04 ` [PATCH v2 1/3] git " tboegi
2018-12-07 21:53   ` Johannes Schindelin
2018-12-08  0:49   ` Steven Penny
2018-12-10  8:46     ` Johannes Schindelin
2018-12-10 12:45       ` Steven Penny
2018-12-11 13:39         ` Johannes Schindelin
2018-12-12  0:42           ` Steven Penny
2018-12-12  7:29             ` Johannes Sixt
2018-12-12 12:40               ` Steven Penny
2018-12-13  3:52                 ` Junio C Hamano
2018-12-12 13:33               ` Johannes Schindelin
2018-12-12  3:47     ` Elijah Newren [this message]
2018-12-12 13:57       ` Johannes Schindelin
2018-12-07 17:04 ` [PATCH v2 2/3] offset_1st_component(), dos_drive_prefix() return size_t tboegi
2018-12-07 17:05 ` [PATCH v2 3/3] Refactor mingw_cygwin_offset_1st_component() tboegi
2018-12-07 22:18   ` Johannes Schindelin
2018-12-08 15:11 ` [PATCH v3 1/1] git clone <url> C:\cygwin\home\USER\repo' is working (again) tboegi
2018-12-08 16:24   ` Steven Penny
2018-12-09  1:39   ` Junio C Hamano
2018-12-10  8:32   ` Johannes Schindelin
2018-12-11  6:12     ` Torsten Bögershausen
2018-12-11 13:28       ` Johannes Schindelin
2018-12-11 18:55         ` Torsten Bögershausen
2018-12-15  4:33 ` [PATCH v4 " tboegi
2019-05-02  7:48   ` Achim Gratz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABPp-BHqJ_Dqpi-N-GVu9difvh-SnD1SZ2-SqaG0ctu5fBX-Tw@mail.gmail.com \
    --to=newren@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=svnpenn@gmail.com \
    --cc=tboegi@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).