2012/4/12 Felipe Contreras <felipe.contreras@xxxxxxxxx>: > 2012/4/12 SZEDER Gábor <szeder@xxxxxxxxxx>: >> On Thu, Apr 12, 2012 at 01:21:17AM +0300, Felipe Contreras wrote: >>> 2012/4/12 SZEDER Gábor <szeder@xxxxxxxxxx>: >>> > However, this change "promotes" the command (or cmd) variable from >>> > being just a variable in _git() to a variable that is used in other >>> > completion functions, too. Why not go one more step further, and >>> > denote this by adding a __git prefix (i.e. renaming the variable to >>> > __git_command)? >>> >>> After thinking more about it, and analyzing the next patches, I don't >>> think it makes sense to have such a variable; it's only used by >>> __git_complete_remote_or_refspec, and it would be easier to make it an >>> argument to that function; that would simplify this patch series a >>> lot. >> >> You mean that _git_fetch() would call >> >> __git_complete_remote_or_refspec "fetch" >> >> while _git_pull() and _git_push() will pass "pull" and "push", >> respectively? > > Yeap. Then there would not be any need for the foo_wrap () stuff. Actually, there would be, we need to call _git_fetch(), but if we have generic wrap function we don't know that; all we have is the alias (e.g. gf from 'git fetch'). I guess we could do something like 'eval $(alias gf)' and find out the right function to call, but that already has an 'eval' there, I'm not sure it's worth it. Any ideas? -- Felipe Contreras -- 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