Re: git-add--interactive works only in top level

Reid Barton [off-list ref] writes:

I understand that programs such as git-add--interactive will be moved
out of the executable path not too long from now, which will also
ameliorate the situation.

Honestly, there is nothing to ameliorate.  We do not even document
git-add--interactive on purpose.

Once I saw somebody who somehow got a root account on a shared UNIX box
and tryed running everything he found under /sbin one after another
without understanding what he was doing.  Needless to say, the box did
not last too long.  Somehow that "tab completion" comment reminds of
him.

El 4/12/2007, a las 7:22, Junio C Hamano escribió:

Reid Barton [off-list ref] writes:

quoted

I understand that programs such as git-add--interactive will be moved
out of the executable path not too long from now, which will also
ameliorate the situation.

Honestly, there is nothing to ameliorate.  We do not even document
git-add--interactive on purpose.

Once I saw somebody who somehow got a root account on a shared UNIX  
box
and tryed running everything he found under /sbin one after another
without understanding what he was doing.  Needless to say, the box did
not last too long.  Somehow that "tab completion" comment reminds of
him.

Here he have two options: blame the user for his/her stupidity, or  
look at this a UI problem and try to make the UI "idiot proof".

In this particular case I see no impediment to favouring the second  
option, because we're not talking about making changes that would make  
Git less powerful or useful for "non-idiots", "power users" or "real  
men" (whatever you want to call them). In other words, we are not  
talking about "dumbing down" Git for the sake of the ignorant. This is  
an opportunity to polish the UI in the same way that we polish the  
internal pack format.

And while it's not a good idea to login as root and try everything  
under "/sbin" without knowing what it does, stumbling across "git-add-- 
interactive" via tab completion is easier to understand. It's an easy  
enough mistake to make and it would be nice if we shielded the user  
from making it.

I think it is (and always was) an error to expose things like git-add-- 
interactive which are fundamentally implementation details *internal*  
to Git. The user shouldn't even know that it exists. It's one thing to  
have a bunch of high-level commands (porcelain) mixed together with  
low-level ones (plumbing) in the user's PATH, but it's another  
entirely to also stick internal implementation stuff which should  
*never* be directly executed in there too. At least in the case of  
plumbing there are reasons why you might sometimes directly execute  
it, but that's not the case with stuff like git-add--interactive.

So I do think there is something to ameliorate, and moving this stuff  
out of the PATH will do exactly that.

Cheers,
Wincent

Hi,

On Tue, 4 Dec 2007, Wincent Colaiuta wrote:

El 4/12/2007, a las 7:22, Junio C Hamano escribi?:

quoted

Reid Barton [off-list ref] writes:

quoted

I understand that programs such as git-add--interactive will be 
moved out of the executable path not too long from now, which will 
also ameliorate the situation.

Honestly, there is nothing to ameliorate.  We do not even document 
git-add--interactive on purpose.

Once I saw somebody who somehow got a root account on a shared UNIX 
box and tryed running everything he found under /sbin one after 
another without understanding what he was doing.  Needless to say, the 
box did not last too long.  Somehow that "tab completion" comment 
reminds of him.

Here he have two options: blame the user for his/her stupidity, or look 
at this a UI problem and try to make the UI "idiot proof".

In this particular case I see no impediment to favouring the second 
option, because we're not talking about making changes that would make 
Git less powerful or useful for "non-idiots", "power users" or "real 
men" (whatever you want to call them). In other words, we are not 
talking about "dumbing down" Git for the sake of the ignorant. This is 
an opportunity to polish the UI in the same way that we polish the 
internal pack format.

You know, without patches you will not convince me ;-)

Ciao,
Dscho

El 4/12/2007, a las 12:48, Johannes Schindelin escribió:

You know, without patches you will not convince me ;-)

A number of patches have already been submitted (by Nguyễn Thái  
Ngọc Duy, I believe); you know, the "Move all dashed form git  
commands to libexecdir" thread and its precursors. I was just arguing  
in support of the rationale behind them.

Cheers,
Wincent

Wincent Colaiuta [off-list ref] writes:

El 4/12/2007, a las 12:48, Johannes Schindelin escribió:

quoted

You know, without patches you will not convince me ;-)

A number of patches have already been submitted (by Nguy

n Tha  

Ngc Duy, I believe); you know, the "Move all dashed form git  
commands to libexecdir" thread and its precursors. I was just arguing  
in support of the rationale behind them.

I think creating separate libexecdir, and moving there _helpers_ first
(i.e. command which are neither plumbing, nor porcelain, but are
meant to be called _only_ by other commands) would be a good idea,
perhaps even pre 1.5.4.

By the way, if (when) dashed form of commands would get moved to
libexecdir, the INSTALL fragment below talking about removin wrapper
script would have to be changed. But does anyone use GNU Interactive
Tools anymore (IIRC the package name was changed to gitfm or sth.)

<quote src="INSTALL">
 - git normally installs a helper script wrapper called "git", which
   conflicts with a similarly named "GNU interactive tools" program.

   Tough.  Either don't use the wrapper script, or delete the old GNU
   interactive tools.  None of the core git stuff needs the wrapper,
   it's just a convenient shorthand and while it is documented in some
   places, you can always replace "git commit" with "git-commit"
   instead.

   But let's face it, most of us don't have GNU interactive tools, and
   even if we had it, we wouldn't know what it does.  I don't think it
   has been actively developed since 1997, and people have moved over to
   graphical file managers.
</quote>

-- 
Jakub Narebski