On Wednesday, April 27, 2011, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Hi Jon, > > I haven't looked into 'git work' yet, but for my own private tweaks, > two mechanisms have sufficed: > > * adding a program named git-foo to the $PATH introduces a > 'git foo' command. For the git command look and feel, scripts > tend to start with > > . "$(git --exec-path)"/git-sh-setup > > (see git-sh-setup(1) for details). > > * various existing git commands can have their behavior modified > through configuration and hooks. > > Does 'git work' require changing the behavior of existing commands, > and if so, are there hooks that could be introduced to help in doing > that? git work is all new, so such considerations don't apply. Actually there is one thing - I proposed a new config variable whose description I left out of the tar ball version because I didn"t want to touch existing files in a git install. The other thing II needed to do was include my man pages so they get picked up by git help. I can see that there might be a class of extension that 'enhances' existing git commands. No doubt that would be a tricky problem to solve and such a solution would not necessarily be good for the git platform in any case. I guess one thing a git plugin architecture could do is provide management of the PATH for plugins, a way to manage man pages and a way to manage plugin specific configuration help. jon. | missed the list unintentionally, the first time through -- 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