Re: [PATCH 1/3] Call extended-semantics commands through variables.

From: Junio C Hamano <junkio@cox.net>
Date: Feb 11, 2006, 06:25 UTC
Message-ID: <7vwtg2mmx5.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <1091.1139614506@lotus.CS.Berkeley.EDU>

Jason Riedy <ejr@EECS.Berkeley.EDU> writes:

Show 5 quoted lines

> The variables are just XARGS, FIND, and CPIO.  No GIT_
> was appended so a user can set those once for all scripts
> that may use them (e.g. configure).  A follow-on patch
> will modify the Makefile to allow installation-specific
> defaults.

The use of FIND or CPIO in git clone does not need -0 (and the code does not use -0, nor your patch adds -0), so you should not have to override them this way. Except refnames, the file names are not something under arbitrary user control and usual LF termination would work fine. Even refnames cannot contain LF in them. Same thing for FIND in ls-remote and git-push.

FIND in count-objects only lists .git/objects/?? so filenames there are already well-behaved and you do not need -0 there for FIND nor XARGS. Same thing for XARGS in git-prune.sh and FIND in repack (BTW, you got count-objects one wrong; there is a leftover GIT_FIND there).

Although most of what your patch does seems to be unnecessary, reviewing this patch gave me an opportunity to see if we fail to use -0 where we should, and I am grateful for it.

I did not see any place we did not use -0 when we should, except one. The places we _do_ use -0 currently should be converted with something like your patch to use -0 capable version of the tool.

The exception is where finding refnames from rsync'ed copy of a remote (the remote may have screwed-up refnames just to be hostile), but nobody should be using rsync transfer anyway, so...