On Sun, Mar 13, 2016 at 10:25 PM, Sidhant Sharma <tigerkid001@xxxxxxxxx> wrote: > > On Monday 14 March 2016 04:58 AM, Jacob Keller wrote: >> On Sun, Mar 13, 2016 at 11:33 AM, Sidhant Sharma <tigerkid001@xxxxxxxxx> 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. >> > I agree that adding `--no-beginner` to all such commands wouldn't be right. In > that case, can we have the flag between git and the command? Such as > `git --no-beginner reset --hard`. If present, the flag can then be removed from > the argument list and the rest of the command executed as is without warning. > Would that a better option? > > > Thanks and regards, > Sidhant Sharma > No, the whole problem with "--no-beginner" is that scripts must either check the configuration variable or add the flag. Since, by definition exactly zero scripts do that today, then every script must either (a) be re-written, (b) accept that some behavior will not work as expected. Most (robust) scripts will already check for aliases, and if not, the user should expect that doing weird things to their environment in this way would cause things to break. I don't think we can create a design where scripts must be re-written to protect themselves or accept misbehaving in those ways. If we had a clear (used) delineation between porcelain and plumbing commands, we could have all the porcelain commands accept an argument but not plumbing. Except that (a) all plumbing commands can be called from the path relatively easily so a user might still want protection on those too and (b) we don't actually have an enforced plumbing/porcelain distinction. While we document one, several scripts exist in the wild which violate this and which we may want to support. I think that we could go this route, but we'd have to be willing to accept (a) or (b), above as costs to this route. Personally I prefer the wrapper approach since it neatly bypasses all of this behavior and seems easier to implement. It's major downside is telling beginners to use "ggit" or similar, which is a big deal. We have broken scripts in the past or changed behavior of commands before. But it is done using a phased transition with lots of warnings. It is possible that the gain is large enough to be worth it. In this case, I think we should heavily way that side because helping people learn git is a huge win. I can't count how many times I've had to tell someone "you really didn't mean to do that" and wished for a way to help avoid this. But, it is a cost to adding an option that any scripting, push/pull hooks or other complex workflows would have to be thought through carefully. Thanks, Jake -- 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