Re: [RFC/GSoC] Introduction

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Sunday 13 March 2016 09:20 PM, Lars Schneider wrote:
> Hi Sidhant,
>
> thanks for your interest in the 'Git Beginner' mode topic. I completely 
> understand your motivation for the topic as your Git learning experience
> matches mine. However, please be aware that this is no easy project. The
> final implementation might be easy but it will require hard work to come 
> up with a design for the beginner mode that the list considers to accept.
> That being said, I am eager to learn about your ideas on the topic :-)
Hi,

I understand that this project will require much effort to find an acceptable
solution and I'm prepared for it. I'm very excited to take this one up :)

> Based on my previous discussions with Junio [3] I think on of the most 
> important aspects is to ensure that Git does not become harder to use.
> 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. 
> If the command is not destructive then 'ggit' would print a short instruction 
> how to "undo" it. The ordinary Git user would not be affected at all by the 
> wrapper. A novice Git user who is unsure about his/her command line
> usage could use `ggit` as a safety net.
>
> I am curious about your opinions on this kind of approach. I wonder if
> people would actually use such a wrapper.
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?

Along with this, the idea of showing a short instruction for undoing commands
sounds very nice as it'll help beginners to understand and use git better.

I'm eager to know your opinions on this approach :)

Other than this, I also tried to expand the list of potentially destructive
commands and updated the list as follows (additions in brackets):

* git rebase [ git pull --rebase ]
* git reset --hard
* git clean -f
* git gc --prune=now --aggressive
* git push -f [ git push <remote> :<branch>, git push <remote> +<branch> ]
* [ git branch -D ]

Are these additions appropriate? What other commands should be included?


Thanks and regards,
Sidhant Sharma


[4]: http://thread.gmane.org/gmane.comp.version-control.git/285893/focus=286663
--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]