On 11/27/2014 06:46 PM, Torsten Bögershausen wrote: > On 2014-11-25 01.28, Michael Haggerty wrote: > [] >> Let me list the aspects of our mailing list workflow that I find >> cumbersome as a contributor and reviewer: >> >> * Submitting patches to the mailing list is an ordeal of configuring >> format-patch and send-email and getting everything just right, using >> instructions that depend on the local environment. > Typically everything fits into ~/.gitconfig, > which can be carried around on a USB-Stick. > Is there any details which I miss, or howtows we can improve ? I used to need one setup at work and a different one at home (because of how my email was configured), and sometimes had to switch back and forth as I carried my notebook around. >> [...] >> * I do "git fetch gitster", then try to figure out whether the branch >> I'm interested in is present, what its name is, and whether the version >> in your tree is the latest version, then "git checkout xy/foobar". > There are 12 branches from mh/, so it should be possible to find the name, > und run git log gitster/xy/fix_this_bug or so. > Even more important, this branch is the "single point of truth", because > this branch may be merged eventually, and nothing else. I know it's *possible*. The question is whether it could be made easier. >> * Following patch series across iterations is also awkward. To compare >> two versions, I have to first get both patch series into my repo, which >> involves digging through the ML history to find older versions, followed >> by the "git am" steps. Often submitters are nice enough to put links to >> previous versions of their patch series in their cover letters, but the >> links are to a web-based email archive, from which it is even more >> awkward to grab and apply patches. So in practice I then go back to my >> email client and search my local archive for my copy of the same email >> that was referenced in the archive, and apply the patch from there. >> Finding comments about old versions of a patch series is nearly as much >> work. > In short: > We can ask every contributor, if the patch send to the mailing list > is available on a public Git-repo, and what the branch name is, > like _V2.. Does this makes sense ? That would be helpful, but it would put yet *another* requirement on the submitter (to send patch emails *and* push the branch to some accessible repository). We regulars could script this pretty easily, but people who only contribute occasionally or who are trying to get started will be even more overwhelmed. > As an alternative, you can save the branches locally, after running > git-am once, just keep the branch. > [] Yes, but it is even more unnecessary manual bookkeeping. > [...] > But there is another thing: > Once a patch is send out, I would ask the sender to wait and collect comments > at least 24 hours before sending a V2. > We all living in different time zones, so please let the world spin once. Yes, good idea. > My feeling is that a patch > 5 commits should have > a waiting time > 5 days, otherwise I start reviewing V1, then V2 comes, > then V3 before I am finished with V1. That is not ideal. One day per patch might be exaggerated, but I agree that long series should be iterated more slowly than short ones. > What does it cost to push your branch to a public repo and > include that information in the email ? One has to run an additional command and add some information to the cover letter, every time a patch series is submitted. If it's scripted then it's relatively painless. But for a newcomer these will be manual steps that are easy to forget or to do incorrectly, making it more likely that the newcomer's first contribution to Git will end in mild embarrassment rather than success. Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx -- 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