On Apr 11, 2014, at 01:48, Matthieu Moy wrote:
"Kyle J. McKay" <mack...@gmail.com> writes:
If script2.sh is changed to this:
# script2.sh fixed
if [ 5 -gt 3 ]; then
case bad in *)
echo always shows
echo should not get here
Wouldn't it be better to just stop using . within function?
The .-ed script could define the complete function, and then the
function would be used from the toplevel script.
If I understand correctly, your version uses nested functions with
inclusion between both levels of nesting. That might work for the
you tested, but if the goal is to avoid using tricky features that may
trigger bugs on some shells, that seems backward.
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.
IOW, why not move the whole run_specific_rebase_internal function to
So what change are you proposing exactly?
The current code in maint does this:
git-rebase.sh: run_specific_rebase_internal() -- contains "dot"
git-rebase--$type.sh: top-level -- has "return"
To make the kind of change I think you're proposing would be somewhat
more invasive than the proposed patch. Each of the git-rebase--$type
scripts would have to be modified not to do anything other than define
functions when included which would require some code movement to
avoid having two "main" functions -- either that or there need to be
multiple "dot" includes in git-rebase.sh so the code not in a function
only executes when the selected case that uses it is active -- or the
entire contents of each git-rebase--$type script gets indented and
becomes a function definition, but that would introduce functions
defining functions which seems like it would add use of a new tricky
feature not previously used.
I'm not saying it's a bad idea, it's just somewhat more invasive than
simply inserting 3 lines.
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