On Sat, Apr 23, 2016 at 06:01:55PM -0700, Kevin J. McCarthy wrote: > As I mentioned earlier, I was still iterating the patches and I posted > them early just for comment. Pushing to a public repos would make it > difficult to modify the patches afterwards. > the ability to easily discard history is possibly _the_ reason why git is objectively superior to hg. of course, this upsets revision control purists who want to never rewrite history, but that attitude plain doesn't work in a project which has any reasonable standards for commit atomicity and quality in general.
(i know that hg gained features to rewrite history later on, but it's all handled as a big exception to the rule, and as mightily dangerous.) > I'm sorry posted patches and the customs of this list are so unpleasant > for you. If you really do want to work _with_ mutt-dev, perhaps you > should make an attempt to adopt our customs rather than demand we match > what you are used to. > to be fair, mutt's way of working is *so* 90's. it simply isn't terribly efficient compared to what an integrated hosting+review platform like github offers (and btw, gerrithub.io is an awesome extension to github). that doesn't mean that you *have* to go with the times, but getting upset when somebody insists that the contribution process is unnecessarily bothersome by modern standards isn't helping, either. imagine this: you fork rich's repo, and work directly with the devel/windows branch (which is just an import of your patches). when you have a new revision of your patch series, you force-push your WIP in addition to posting the patches to the list. actually, the latter could be automated by installing a webhook on gerrit. in addition to making your WIP more easily accessible for testing and followup work (a pull is *so* much faster than wading through patches on the list), you can also accept feedback directly on github (and/or gerrithub), and even ensure that the list sees all of it by creating a github account for it and making it a watcher for your repo. when the commits are ready, you push to hg (through the git frontend). you can enable 3rd party contributions by being liberal with push rights to the github repo - no big deal, as it's not authoritative anyway. some sort of "dvcs-based shadow repository" is in fact something that some major projects have adopted over time, in particular those that prefer to stay with svn as their master repository, be it for reference continuity, big files, or whatever. you don't lose anything (except for some time for setting up the accounts and hooks, and possibly getting used to git), your workflow stays almost identical, and yet, the mutt development process arrives in the 21st century.
