Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

> 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.

> 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.

> 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).