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

Jonathan Nieder [off-list ref] writes:

Thiago Farina wrote:

quoted

All patches should just fix real problems?

Yes.

This answer while it is correct needs to be qualified ;-)

A bugfix for end-user facing part of the system is obviously a fix for a
"real problem", but clean-up without changing external behaviour to reduce
maintenance burden in the longer term also is fixing a real problem, i.e.
"the code, while it might be bug-free, is error prone and costs a lot to
maintain".

What happened to this patch? I can't see it on any branch (master, pu, maint).

Thiago Farina wrote:

What happened to this patch? I can't see it on any branch (master, pu, maint).

I thought there was some discussion about another binary in
/usr/lib/git-core being a bad thing?

On Wed, Oct 27, 2010 at 1:18 PM, Jonathan Nieder [off-list ref] wrote:

Thiago Farina wrote:

quoted

What happened to this patch? I can't see it on any branch (master, pu, maint).

I thought there was some discussion about another binary in
/usr/lib/git-core being a bad thing?

I don't recall, why it's a bad thing?

Thiago Farina wrote:

On Wed, Oct 27, 2010 at 1:18 PM, Jonathan Nieder [off-list ref] wrote:

quoted

I thought there was some discussion about another binary in
/usr/lib/git-core being a bad thing?

I don't recall, why it's a bad thing?

Because those hardlinks for builtins are present for historical reasons
only.  They slow down filename lookup by some miniscule amount and tempt
authors of scripts to try the dashed form of commands.

Ah, found it.[1]

| At this point, adding the dashed-form "git-version" to the filesystem is
| going backwards.  These files are only to help people who have old scripts
| from pre 1.6.0 days with "PATH=$(git --exec-path):$PATH" with their
| environment.
| 
| We should instead try to not adding them (which would probably need tweak
| in the command list generation code in "git help"), as nobody from pre
| 1.6.0 era would have called "git-version" binary.

Hope that helps.

[1] 4a7a62f3:whats-cooking.txt
http://thread.gmane.org/gmane.comp.version-control.git/155073

On Wed, Oct 27, 2010 at 2:45 PM, Jonathan Nieder [off-list ref] wrote:

Ah, found it.[1]

| At this point, adding the dashed-form "git-version" to the filesystem is
| going backwards.  These files are only to help people who have old scripts
| from pre 1.6.0 days with "PATH=$(git --exec-path):$PATH" with their
| environment.
|
| We should instead try to not adding them (which would probably need tweak
| in the command list generation code in "git help"), as nobody from pre
| 1.6.0 era would have called "git-version" binary.

Hope that helps.

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

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

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.