Re: [PATCH] help.c: Pull cmd_version out of this file.

[Jonathan Nieder <jrnieder@gmail.com>]

Thiago Farina wrote:

> Nope, sorry. I don't fully understand his explanation.

Any questions then?

> Also, Junio, thanks for the "I don't like
> churning-for-the-sake-of-churning". This is very incentive.

For the scenario "one person likes this change and another doesn't",
in the Linux kernel world (which I find amusing to take as a model),
there is a well established method to deal with that.  (I'm a big fan
of this method.)  It works like this:

 1. Write a patch.
 2. Send a copy to the list and get feedback.
 3. Use it locally.  Foist it on your friends.  Accept bug reports
    and keep a git tree to handle them.  When conscience or users
    provide the pressure for it, move on to step 4:
 4. Send another report to the list and get more feedback.
    ...
 n. (Ideally) the patch evolves to be more useful.  Eventually, it
    gets applied upstream or, if upstream is out of touch, the
    patched version becomes the new mainstream.

Why am I saying such things?  Isn't it extreme to ask you to take
matters into you own hands, especially for such an unrisky patch?

What I want to get at is that to make your work available, you don't
need Junio.  You can do that yourself.  It can still be very useful
to people!  What Junio offers is help in maintaining code --- once a
patch hits mainline, there is no need to keep forward-porting it, you
are less alone in dealing with bug reports, you will find more people
out there to give advice in changing it for new requirements.

So when someone like Junio says

 I don't like churning for the sake of churning

part of what this means is that in order to take on new code, there
has to be an obvious benefit that outweighs the maintenance burden.
(Keep in mind: "obvious" doesn't mean "big", it just means "clear".)

What maintenance burden?  Here, I thought I had explained that if
it weren't for existing scripts, there would not be more than one
hardlink for builtins in /usr/lib/git-core at all.  Those hardlinks
are technically just bad --- they require munging the PATH and
basing behavior on argv[0], they are confusing, their command-line
syntax is not as flexible as the git <options> foo syntax, and use
of them makes it hard to grep for a real bug that some old programs
have of assuming dashed-form commands are in the user's $PATH.

So your patch is exciting in a way, because it serves as a reminder
of a problem it would be nice to solve (that each new builtin adds
to the builtins in /usr/lib/git-core for no good reason and that
'git help' is relying on that).

Sorry to be vague, hope that helps.