John Keeping <john@xxxxxxxxxxxxx> writes:
> On Wed, Jun 01, 2016 at 03:07:59PM -0400, Jeff King wrote:
>> On Wed, Jun 01, 2016 at 07:31:00PM +0100, John Keeping wrote:
>>
>> > > > reset_submodule_urls () {
>> > > > - local root
>> > > > - root=$(pwd) &&
>> > > > (
>> > > > + root=$(pwd) &&
>> > > > cd super-clone/submodule &&
>> > > > git config remote.origin.url "$root/submodule"
>> > > > ) &&
>> > > > (
>> > > > + root=$(pwd) &&
>> > > > cd super-clone/submodule/sub-submodule &&
>> > > > git config remote.origin.url "$root/submodule"
>> > [...]
>> > I wonder if it's relevant that the "local root" line isn't &&-chained?
>> > Is it possible that on some shells we ignore an error but everything
>> > still works?
>>
>> I don't think so. We're inside a function, so we wouldn't affect any
>> outer &&-chaining in the function (and there isn't any in the caller
>> anyway). I think it's a reasonable custom not to bother &&-chaining
>> "local" lines, as they come at the top of a function and can't fail.
>
> Can't fail if the shell supports "local", but if we're in a shell that
> doesn't support it, then the lack of "&&" may allow us to just carry on.
True, but if "to just carry on" were a correct behaviour, then
wouldn't that mean that "local" was unnecessary, i.e. the variable
did not have to get localized because stomping on the global name
would not affect later reference to the same variable made by the
caller?
If the clobbering of a global variable breaks the behaviour of the
script, wouldn't we rather want to catch that fact?
So either way, I do not think "local variable names" that breaks
&&-chain can be justified. Either the variable must be localized
for the script to work correctly, in which case we want local with
&&-chaining, or it does not have to, in which case we do not want to
have "local" that is not necessary, no?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html