Josh Triplett <j...@joshtriplett.org> wrote:
> On Tue, Aug 09, 2016 at 06:28:00PM +0000, Eric Wong wrote:
> > Some of these problems I hope public-inbox (or something like
> > it) can fix and turn the tide towards email, again.
>
> This really seems like the dichotomy that drives people towards central
> services like GitHub or GitLab. We need an alternative that doesn't
> involve email, or at the very least, doesn't require people to use email
> directly. Half of the pain in the process comes from coaxing email
> clients that don't treat mail text as sacrosanct to leave it alone and
> not mangle it. (Some of that would go away if we accepted attachments
> with inline disposition, but not all of it. All of it would go away if
> the submission process just involved "git push" to an appropriate
> location.)
I don't mind patches as attachments and did some work a few
months ago to ensure they're individually downloadable in the
public-inbox WWW interface (along with full mboxrd messages)[1].
Fwiw, attachments are preferred in perl5-porters, and it might
be acceptable on LKML, even. Not my call, though.
Having a push/pull-only workflow would still require some sort
of messaging system to notify others. Ideally that message
would have the output of "git request-pull" to ensure people are
on the same page; but I'd prefer patches (either attachments or
inline) continue to be sent anyways in case the server is down
or the reader is offline or on a machine without git.
[1] see Brian's (who is new, here) initial email for diff-highlight:
https://public-inbox.org/git/20160728162712.ga29...@tci.corp.yp.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
