Re: [PATCH 1/3] rebase: avoid non-function use of "return" on FreeBSD

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

"Kyle J. McKay" <mackyle@gmail.com> writes:

> On Apr 11, 2014, at 10:30, Matthieu Moy wrote:
>> "Kyle J. McKay" <mackyle@gmail.com> writes:
>>
>>> There are already nested functions with file inclusion between both
>>> levels of nesting in git-rebase--interactive.sh and git-rebase--
>>> merge.sh now, so it's not introducing anything new.
>>
>> OK, so it's less serious than I thought. But still, we're
>> introducing a
>> function with 3 levels of nesting, split accross files, in an area
>> where
>> we know that at least one shell is buggy ...
>
> Currently in maint:
>
> The current code in maint does this:
>
> git-rebase.sh: top-level
>   git-rebase.sh: run_specific_rebase()
>     git-rebase.sh: run_specific_rebase_internal() -- contains "dot"
>       git-rebase--interactive.sh: top-level (using --continue or -- 
> skip)
>         git-rebase--interactive.sh: do_rest
>           git-rebase--interactive.sh: do_next

You're confusing function calls and function nesting. do_rest calls
do_next, but the definition of do_next is not nested within do_rest.

When I talk about nested function, I mean

f() {
	g() {
		...
	}
}

Obviously, having functions call each other is not an issue. That's what
functions are meant to be.

Now, having run_specific_rebase_internal include a file which defines
functions which contain nested functions _is_ something I find weird. It
both stresses the shell in a buggy area and makes the code harder to
understand.

> The problem with these changes, particularly the git-rebase-- 
> interactive.sh one is that a bunch of code is still run when the file
> is "dot" included.

Function definitions, and variables assignments. Is it so much of an
issue?

What's the difference between a function definition or variable
assignment within git-rebase--*.sh and within git-rebase.sh?

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/