Thread (5 messages) flat view 5 messages, 3 authors, 2016-06-15

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

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:45:04

Possibly related (same subject, not in this thread)

Hi,

On Tue, 29 Jul 2008, Steffen Prohaska wrote:
On Jul 29, 2008, at 7:24 AM, Shawn O. Pearce wrote:
quoted
Steffen Prohaska [off-list ref] wrote:
quoted
We prefer running the dashless form, so we should use it in MinGW's 
start_command(), too.
...
quoted
- We have non-builtins that are implemented in C, e.g. fast-import.c.
  These non-builtins will still compute wrong paths.
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.
For builtins it is not a work around but a real solution.
No, it is not a real solution.  At least not for the goal you stated: 
getting the correct "toplevel" directory.  It is a workaround, because it 
avoids the builtins being called as proper programs (which they should be 
perfectly capable of, and which scripts still _are allowed to do_).

However, it is a solution.  To a totally other problem, namely "I would 
like to be able _not_ to install the builtins into the exec-path".  Sure, 
you break a few scripts that rely on the builtins being callable in the 
dash-form, but at least the scripts we ship in git.git are safe.

Ciao,
Dscho
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help