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

[Eric Wong <e@80x24.org>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> BTW I take this thread as yet another proof that people are unhappy with
> mail list-based review: if you have to build *that much* tooling around it
> (and Peff & Junio certainly have a megaton of advanced and sophisticated
> tooling around it, holy cow!) it is really incorrect to state that the
> mail list-driven approach works for you. It is much closer to the truth to
> say that the mail-list-plus-loads-of-custom-tools-driven approach works
> for you.
> 
> I am really not a fan of this.
> 
> The theory "it's inclusive because everyone has access to mail" falls on
> its face, badly, when even old timers have to build entire infrastructures
> around it just to begin to be able to use it efficiently.
> 
> It reminds me of an old software developer I met long ago, who claimed CVS
> works for him. He had written tens of thousands of lines of shell scripts,
> is what allowed "CVS" to work for him.
> 
> Same here. Old dogs claim the mail list-approach works for them. Nope.
> Doesn't. Else you would not have written all those custom scripts.

git and cogito started as a bunch of custom scripts, too.
IMHO, it's what makes Free Software (and *nix) great:
users have control to customize and improve things.
With scripts, they don't even need to learn a build process
to do so.

I see a choice of mail client as no different than a choice of
text editor.  Neither my mail client or text editor is heavily
customized.  The key feature I rely on from both tools is piping
data to external commands.


OTOH, today, I see people using git aliases all the time which
look more like ASM instructions than user commands.

Is the widespread use of these aliases a deficiency to git?
Maybe, I don't know.

Normally, I do not care about aliases: it's a private thing;
but it also makes it incredibly difficult for me to help
users when they're exposed in public.


Users ought to be able to pick, choose, and replace tools as
they wish as long as an interchange format remains stable
and widely-supported.

Fwiw, I still use patch(1) pretty often, even on patches
generated with git.  I see nothing wrong with that; patch is
lenient in ways git-apply was explicitly designed not to be.
And I don't always use git send-email or my normal MUA for
sending; or use git for generating diffs.  I do:

	diff -u a b | mail -s WIP-blah-blah $SOMEONE


While you and I are long-time git hackers, I don't think it's
reasonable for everyone to use git or git-specific tools;
even to git.git for one-offs like portability or doc fixes.

Even today, at least one Linux kernel hacker still uses quilt to
generate patches: http://ozlabs.org/~akpm/mmotm/