Hi Junio, On Tue, 2 Aug 2016, Junio C Hamano wrote: > So either I should change my workflow and mention any and all > typofixes in my review comments (which consumes the review > bandwidth), or I should force patch authors to do the "fetch from > 'pu' and replace" somehow to avoid this kind of back-and-forth. It never occurred to me that I should replace any of my local branches with versions you have in `pu`. For several reasons: - just as you do not pull from me, lest patches enter your repository that you have not reviewed, I do not simply pull from you, - I thought the point of avoiding GitHub in the review process at all costs and require everybody to go via the mailing list instead was to keep the review process open? These silent changes fly in the face of that, - I agree that the mail-based process is cumbersome and error-prone, but we won't fix it by asking contributors to dig through the `pu` of the day, somehow stay up-to-date with possibly more silent typofixes the next day, somehow manage to figure out what changes exactly were introduced to their patches, and replace their local work. - even if we asked for all that trouble, the commits in `pu` are all signed off by you. These sign-offs would have to be stripped out tediously when making local changes. In short, I agree that our patch submission process is a saber tooth tiger that still reflects pre-Git times. While we use Git's tools, the workflow really tries to cut out Git as much as possible, in favor of pure mails with non-corrupted, non-HTML patches in them, a charmingly anachronistic requirement until you try to use state-of-the-art mail clients to send them. I disagree, however, with the suggestion to sift through your `pu` branch and to somehow replace local branches with the commits found there. I guess it is time to revisit our patch submission process if it does not even work between the two of us. Ideally, we would come up with a process that - makes everything easier for maintainers and contributors alike, - tracks the history of the patch iterations (answering the question "what changed between iterations?"), - *actually* integrates with Git (to see what I mean, try to find the commit corresponding to a given mail containing a patch, and then try to find the previous iteration's version of the same commit, and weep), - provides machine-readable metadata about the context, e.g. to jump back and forth between the full file contents and the patch, or to indicate the dependency on another branch, - facilitates "back contributions", i.e. letting contributors accept changes suggested by reviewers *with minimal effort*. - uses Git itself as much as possible, i.e. no additional tools written in "you must learn this new language, it's awesome, believe me, it's huge" The biggest obstacles I see are 1) the integration with the mailing list (which is ironic because contributing via the list used to be a boon, not a burden) and 2) maintaining the integrity between what has been reviewed and what is actually in the branch. This is nothing we will solve overnight, of course. But I think we will have to fix this. Food for thought. Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html