On 14-11-28 09:31 AM, Michael Haggerty wrote: > 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. A bot could subscribe to the list and create branches in a public repo. (This idea feels familiar -- didn't somebody attempt this already?) Integrate the bot into the list manager, and every PATCH email sent through the list could have the patch's URL (maybe in the footer, or as an X- header). Could this make a decent GSoC project? M. -- 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