Lars Schneider <larsxschneider@xxxxxxxxx> writes: > I thought a while about this requirement and I wonder if a wrapper called > 'ggit' (guarded Git) could be a solution. The wrapper would pass all > command line arguments to 'git' and check for potentially destructive > commands. If such a command is detected then the user would see a warning. I recall back in the days when people said that Hg's command set was so much more pleasant to use that some people thought about building Hg's command line UI on top of low level implementation of the Git's data structure. Even before that time, there was an effort "Cogito" to build an alternate UI on top of Git core. If "ggit" can be made reasonably feature complete in such a way that it lets beginners do all what they need to do, omitting many advanced/hairy features core Git may let users use (i.e. making trade-off between power and risk of misuse differently from core Git), that may be a reasonable way to offer a "beginner mode". The beauty of such an approach is that as long as "ggit" correctly talks the same on-wire protocol when interacting with other people's repositories, nobody needs to even know or care that you are using "ggit" exclusively. Two systems can talk without problems. If "ggit" is made too limited, there is an issue. Beginners may at some point need to transition to the real thing to fully exploit the power of Git, and they may need to unlearn "ggit" and learn Git. This approach, if it wants to become successful in helping users, would take quite a lot of thinking and work to avoid omitting too much to necessitate users to migrate to Git. But I can very well imagine that a new "Cogito 2" project (I am not saying that the UI Cogito tried to achieve were superiour or anything of that sort--I just needed a name, and picked one name that came to my mind) may get done by those who interact rarely with the core Git community and may live as one of many independent and viable third-party projects you find on GitHub. There however are two questions I do not offhand have good answers to: (1) if that kind of effort is of suitable size for GSoC, and (2) if it is suitable to be supported by the Git project proper. -- 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