Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > There are things we get out of this that would regress if > submitGit were changed this way: > > * Now when you submit a pull request you get a Travis build for > git/git, I don't get this if I push to any random branch in my > avar/git, and although I could probably set it up, it's extra work > etc. Thanks for pointing this out. I agree that this indeed is a downside. > * I like being able to "git fetch" patches I'm reviewing. Now I can > just set "+refs/pull/*:refs/remotes/origin/pull/*" in the refspec for > git/git, if it were pulling from target repos I'd need to "git remote > add" for each one, not a big deal, but less convenient. > > * There would be no single place to list submitGit requests, which > you can do now through the pull page, although I think this is largely > stale now because nothing auto-closes them if they're merged (by which > point they'll have different sha1s), but that could be improved with > some bot... I do not think these two are 'regressions', unless your definition of 'regression' is a "this thing I used to be able to do, now I no longer can", which is slightly different from mine, which is "this useful thing I used to be able to do, now I no longer can". It would be useful to be able to do the above two things, if the list of submitGit requests and what you can get from pull/* hierarchy (1) covered most of the changes proposed, allowing people to check only this place and nowhere else, and/or (2) covered the more interesting changes that are worth looking at than other proposed changes. I do not think either is the case. The submitGit mechanism being an easier way to propose a change to the mailing list, by definition, (1) will not hold true. And among the changes proposed to be made to Git, the "selection criteria" to be in the set to be discoverable by going to github.com/git/git.git and checking the submitGit pull requests is not that they are of higher quality or touch interesting topics. The only common trait these proposed changes share, compared to other proposed changes we see on the mailing list, are that they were originally made as pull requests and (2) will not hold true. Another thing that may regress that you did not mention is that we would lose a convenient way to _count_ proposed changes coming via submitGit (i.e. you can simply go to the pull-request page), so that the number can be compared with the number of proposed changes directly made on the mailing list, which would be a good way to gauge how submitGit service is helping our community. But even for that, you'd need to go to the list to find the denominator (i.e. total number of changes proposed), and by the time you do that, counting the numerator (i.e. those come via submitGit) by finding the telltale sign submitGit leaves in its output among these denominator messages should be trivial. So in all, I see the only downside is the loss of automated triggering of Travis. But I do agree with you that it is a rather significant downside. > There's probably ways to do this without git/git pull requests, but I > don't see what problem would be solved by moving this off git/git, > even if there's open requests submitGit is the only thing using these, > and any confusion about that pull UI would remain if it wasn't (AFAIK > there's no way to completely disable pull requests on github, but I > may be wrong). Hopefully the pull-request template update Lars proposes will keep the pull request useful, in that they create one and then have submitGit relay it to the official channel.