Hi Junio, On Wed, 15 Feb 2017, Junio C Hamano wrote: > 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. That is the reason why set aside a substantial part of my maintainer time to upstream those patches. You may not see how much time it costs me, say, to get the putty-w-args stuff upstream, but rest assured that I would not be able to do this were it not for a company paying me to do exactly that. > > 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. The problem here is that Git for Windows is not a subsystem. It touches pretty much all of Git. That is very different from the Tcl/Tk code, or from git-svn (whose code is not shared by anything else in Git's source code, despite the fact that it is written in Perl). And even if you were to accept the occasional Pull Request from me, it would not solve the even bigger problem that we essentially reject so much expertise out there, so many potential contributions by very competent developers who just have no desire to fight the contribution process. > 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 ... or her... > 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. Apart from the fact that we have no prayer at coming up with a system that keeps track of open issues (because we do not use any tracker, but instead rely on people to remember that some thing still may not have been addressed), there is a different problem here: you stated very explicitly that it is okay for `pu` to be broken [*1*]. If it were different, if any breakage would imply that a fix is really, really required lest the patch series be evicted from `pu`, we could easily modify my Continuous Testing setup to report more visibly what is broken. But since it is okay for `pu` to be broken, that would just annoy everybody and people would learn to ignore/procmail those reports. > The CI you are setting up [*1*] which *1*? And... I already set it up. I just did not bother to make it more public because the builds were broken more often than not. IIRC the entire month of October was a solid red. > 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? The Continuous Integration is actually not so much a Continuous Integration as it is a Continuous Testing. If it became more of a CI, that would certainly reduce the impression that Git's bleeding edge only ever works on Linux. Ciao, Johannes Footnote *1*: You probably read between the lines that this is unfortunate, in my opinion. It sets the mood that lets experimental (if useful) features such as worktrees be broken for the better part of a year.