Re: [PATCH 2/2 v2] run-command (Windows): Run dashless "git <cmd>" (solves part of problem with system_path)

"Shawn O. Pearce" [off-list ref] writes:

This feels wrong to me.  fast-import probably won't be adversly
impacted by not being able to read /etc/gitconfig, unless the user
has set something like core.deltaBaseCacheLimit and is doing an
incremental import.  But other non-builtins may be impacted.

It feels like we're fixing this in the wrong place.  If the issue
is we don't find our installation directory correctly, we should
find our installation directory correctly, not work around it by
calling builtins through the git wrapper.

Though I can see where it may be a good idea to at some point
in the future (git 1.7?) stop creating the redundant builtin
links under libexec/git-core.

I agree; that is why I already applied Steffen's original patch with quite
a different justification from the updated one:

commit b048b9a803f48d88595877271b53bf9ec400e4ba
Author: Steffen Prohaska [off-list ref]
Date:   Mon Jul 28 07:50:28 2008 +0200

    run-command (Windows): Run dashless "git <cmd>"
    
    We prefer running the dashless form, and POSIX side already does so; we
    should use it in MinGW's start_command(), too.
    
    Signed-off-by: Steffen Prohaska [off-list ref]
    Acked-by: Johannes Sixt [off-list ref]
    Signed-off-by: Junio C Hamano [off-list ref]

On Jul 29, 2008, at 7:42 AM, Junio C Hamano wrote:

"Shawn O. Pearce" [off-list ref] writes:

quoted

This feels wrong to me.  fast-import probably won't be adversly
impacted by not being able to read /etc/gitconfig, unless the user
has set something like core.deltaBaseCacheLimit and is doing an
incremental import.  But other non-builtins may be impacted.

It feels like we're fixing this in the wrong place.  If the issue
is we don't find our installation directory correctly, we should
find our installation directory correctly, not work around it by
calling builtins through the git wrapper.

Though I can see where it may be a good idea to at some point
in the future (git 1.7?) stop creating the redundant builtin
links under libexec/git-core.

I agree; that is why I already applied Steffen's original patch with  
quite
a different justification from the updated one:

commit b048b9a803f48d88595877271b53bf9ec400e4ba
Author: Steffen Prohaska [off-list ref]
Date:   Mon Jul 28 07:50:28 2008 +0200

   run-command (Windows): Run dashless "git <cmd>"

   We prefer running the dashless form, and POSIX side already does  
so; we
   should use it in MinGW's start_command(), too.

Thanks for reading my mind ;-)  This was the alternative justification
I had in mind after reading my patch again.

	Steffen

Hi,

On Tue, 29 Jul 2008, Steffen Prohaska wrote:

On Jul 29, 2008, at 7:42 AM, Junio C Hamano wrote:

quoted

  We prefer running the dashless form, and POSIX side already does so; 
  we should use it in MinGW's start_command(), too.

Thanks for reading my mind ;-)  This was the alternative justification I 
had in mind after reading my patch again.

Well, given that the justification you gave had the obvious flaw -- which 
you even pointed out -- that non-builtins are _still_ affected, i.e. that 
you leave that bug unfixed (but your description purports that you want to 
fix that bug), it would have been wiser to give the alternative 
justification, which makes the commit obviously correct.

Ciao,
Dscho

On Jul 29, 2008, at 1:13 PM, Johannes Schindelin wrote:

On Tue, 29 Jul 2008, Steffen Prohaska wrote:

quoted

On Jul 29, 2008, at 7:42 AM, Junio C Hamano wrote:

quoted

 We prefer running the dashless form, and POSIX side already does  
so;
 we should use it in MinGW's start_command(), too.

Thanks for reading my mind ;-)  This was the alternative  
justification I
had in mind after reading my patch again.

Well, given that the justification you gave had the obvious flaw --  
which
you even pointed out -- that non-builtins are _still_ affected, i.e.  
that
you leave that bug unfixed (but your description purports that you  
want to
fix that bug), it would have been wiser to give the alternative
justification, which makes the commit obviously correct.

We still need to fix the problem with system_path(), because currently
we cannot release Git-1.6.0 on Windows.  That is why I pointed out the
real problem we are facing.  The (good) side-effect is that the
MSYS-codepath is now prepared for 1.7.

	Steffen