"Kyle J. McKay" <mack...@gmail.com> writes:
> On Apr 11, 2014, at 10:30, Matthieu Moy wrote:
>> "Kyle J. McKay" <mack...@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
>> 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 --
> 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
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
> 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
What's the difference between a function definition or variable
assignment within git-rebase--*.sh and within git-rebase.sh?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html