Re: [PATCH] git-version-gen: include command name in one more diagnostic

[Jim Meyering]

Bruce Korb wrote:
> On 01/03/11 09:56, Jim Meyering wrote:
>> Did you determine which git command failed and why?
>
> There was only one git command that did not have stderr redirected:
>           numcommits=`git rev-list "$vtag"..HEAD | wc -l`
> But in truth, *no* git command should have its error output
> displayed without proper git-version-gen context.  Or "cat"
> either, for that matter.
>
>> The only git commands that git-version-gen should be running
>> these days are git describe (it runs git rev-list only to accommodate
>> very old versions of git), git update-index, and git diff-index.
>
> Does that "git diff-index" really need to be run in a separate
> shell invocation?
>> dirty=`sh -c 'git diff-index --name-only HEAD' 2>/dev/null` || dirty=

Yes.  As I recall, that was required in order to ensure that even when
the shell fails to find a "git" program, the stderr output
is redirected.

> How is that different from:
>> dirty=`git diff-index --name-only HEAD 2>/dev/null` || dirty=
> exported variables get passed through either way.....
>
> But also note that this script will be run from a tarball
> in an environment where there may well be some waaaay out of
> date git (assuming git is there at all).

The recommended way to run git-version-gen
ensures that when run from a just-unpacked tarball,
it has a file name argument (.tarball-version),
and in that case, the script uses its contents
and doesn't even attempt to use git.
See the comments at the top of git-version-gen for details.

>>> I'll supply that patch, if you like.
>
> Your "commit_list" patch should fix the issue.
>
>>> Is it okay to use the post-1977 concept of a shell function?
>>> Even the Solaris /bin/sh supports it .....
>>
>> Yes, it inherits portability constraints from configure,
>> which now uses shell functions.
>
> Maybe Open Solaris will move /bin/sh to something not over 20 years
> old and things can move along? :-D

I have ;-)
at least in most bourne shell test scripts I write these days,
where I now assume "local" works, along with everything POSIX.

If you find yourself to be too hamstrung by shell portability
constraints, consider the techniques in tests/init.sh, whereby it
ensures/finds a "usable-enough" shell and (if needed) re-execs it.

gnulib-tool and configure scripts do the same thing, but don't
try as hard as init.sh does to find the shell features I now require.