On Sun, Mar 13, 2016 at 11:33 AM, Sidhant Sharma <tigerkid...@gmail.com> wrote: > Coincidentally, my approach too is a wrapper around git as you suggest. > The approach is simple and straight forward, but I wasn't sure if it would be > accepted on the list, mainly because it may not look consistent with the > current > interface `git command [options]`. Perhaps a configuration like > `core.beginnerMode` [4] might be apt? By default, it can be false, making git > behave normally. When set, a safety-check can be run before the command is > executed to ensure it's not potentially destructive. Very much like a wrapper > but on the inside. There can be an option like `--no-beginner` to override > this configuration from the command-line. I was wondering if there should be > command-specific options as well, such as `beginner.allowForcePush`, > `beginner.allowRebase` etc. for a finer control over what commands git would > warn > the user about. By default, all are set to false, and warning is shown when > any > of them is encountered. Another configuration that may be considered is > `beginner.strict`, which when set would just print the warning and die, > instead > of giving the user an option to continue (though I'm a little unsure whether > this one would be a good idea). > One thing that bothers me about this approach is that unlike the explicit > 'ggit' > wrapper, an internal wrapper would add (unnecessary?) overhead for most > commands, > thus impacting the performance. Will that be an issue? >
If I recall correctly, a configuration setting was previously discussed but mostly discarded as a solution since any changes had better not impact any current scripts. Having to add "--no-beginner" for all of them seems unacceptable. Especially since many scripts may do potentially dangerous operations in a safe or useful way. Thanks, Jake -- 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
