Junio C Hamano <gitster@xxxxxxxxx> writes: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > >> FWIW I wish it were different, that git.git's `master` reflected more >> closely what the current Git for Windows version has. > > Well, we two wishing the same thing together without doing anything > else would make it happen. ehh, would *not* make it happen, of course. > As an experiment to see if our process can be improved, I've been > meaning to suggest (which is what was behind my "question at a bit > higher level" to Hannes [*1*]) asking you to throw me occasional > pull requests for changes that are only about Windows specific > issues, bypassing "patches on the list" for things like a hotfix to > js/mingw-isatty [*2*] and use of OpenSSL SHA-1 on Windows [*3*], > essentially treating Windows specific changes as "a sub-maintainer > makes pull requests" we already do with Paul, Eric and Pat. While this may ease the flow of upstreaming windows specific changes, we need a separate thing to address the on-going issue you raised in your message. A Windows-less person would not know his change to a generic code that is innocuous-looking has fallouts on Windows (read this sentence with "Windows" replaced with any specific platform name). When somebody writes c == '/' that should have been written as is_dir_sep(c), you or Hannes often finds it during the review here, and after repeatedly seeing such reviews, that (slowly) rubs off on other Window-less folks. A new code may still hit 'next' and 'master' with such an issue if it goes unnoticed during the review. The CI you are setting up [*1*] may certainly be a step in the good direction. Having more people like Hannes working off of upstream may also be a great way to help the "forget 'next' and upstream in general" issue. Any other ideas?