W dniu 19.08.2016 o 17:03, Jeff King pisze: [...] > There is nothing wrong with building tooling around your workflow. If we > had a GitHub-based workflow, I'd build tooling around that, too. One of > the things I _like_ about a mail-based workflow is how easy it is to > build that tooling, and to get it to integrate with other existing > tools. It's the major reason I'm resistant to moving development to > GitHub. Not only would I have to throw away all of my tools, but I'm not > sure I could easily build equivalent ones. Also, you would have the same problem with tooling around specific Git hosting site as there is with tooling around specific email client. Tool that works with GitHub (like submitGit) won't work with Bitbucket or GitLab. Well, unless such tooling was built in in all hosting sites. They have support for sending mails anyway, isn't it? But perhaps the problem is current lack of tooling in the opposite direction, namely getting patches from mailing list and applying them to GitHub repo, or Bitbucket, or GitLab. Though with working Git, it is something easier than sending patches via email; it is enough that email client can save email to a file (or better, whole sub-thread to file or files). Also, there is lack of tools that convert inline (in-diff) comments on GitHub (or Bitbucket, or GitLab) to email with review... There is also distrust for centralized solutions (email is, in principle, decentralized). See projects like https://solid.mit.edu, etc. > Now, I am perfectly open to the idea that more of the tooling should be > standardized, so people do not have to build their own. But the major > problem there is that so much of what I've built is about gluing things > together for the rest of _my_ tools. I've shared my techniques and > scripts for using mutt several times, but they don't do somebody a lick > of good if they are using gmail or thunderbird. It would be nice to have links to those tools in SubmittingPatches and/or the Git homepage. [...] > PS There _are_ some open questions in our workflow that are not really > mailing list specific. E.g., the fact that it is hard to see whether > and if your patch was picked up by Junio, what changes were made, > tracking multiple versions, etc. I _don't_ have good tooling for > that, but it's something that could be made generally available, as > it's unrelated to the MUA. It's also not necessarily specific to > mailing list development (e.g., a push-based workflow that > aggressively rebases runs into the same versioning questions). Well, "What's cooking ..." and 'pu' branch helps, I think. -- Jakub Narębski -- 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