From: Sidhant Sharma <tigerkid001@gmail.com>
To: Lars Schneider <larsxschneider@gmail.com>,
Junio C Hamano <gitster@pobox.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [RFC/GSoC] Introduction
Date: Mon, 14 Mar 2016 00:03:33 +0530 [thread overview]
Message-ID: <56E5B27D.7010808@gmail.com> (raw)
In-Reply-To: <1924FEBB-46F2-46EE-B190-5289588D4BED@gmail.com>
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
next prev parent reply other threads:[~2016-03-13 18:35 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-12 6:59 [RFC/GSoC] Introduction Sidhant Sharma
2016-03-13 15:50 ` Lars Schneider
2016-03-13 18:33 ` Sidhant Sharma [this message]
2016-03-13 21:19 ` Kevin Daudt
2016-03-14 5:25 ` Sidhant Sharma
2016-03-14 6:15 ` Jacob Keller
2016-03-14 7:01 ` Junio C Hamano
2016-03-13 23:28 ` Jacob Keller
2016-03-14 5:25 ` Sidhant Sharma
2016-03-14 6:14 ` Jacob Keller
2016-03-14 16:00 ` Sidhant Sharma
2016-03-14 6:57 ` Junio C Hamano
2016-03-14 8:16 ` Lars Schneider
2016-03-14 15:56 ` Sidhant Sharma
2016-03-20 20:17 ` Matthieu Moy
2016-03-14 17:25 ` Junio C Hamano
2016-03-20 20:28 ` Matthieu Moy
2016-03-14 21:08 ` Philip Oakley
2016-03-17 14:52 ` Sidhant Sharma
2016-03-20 15:39 ` Lars Schneider
2016-03-20 15:51 ` Sidhant Sharma
2016-03-20 16:08 ` Lars Schneider
2016-03-20 16:22 ` Sidhant Sharma
-- strict thread matches above, loose matches on Subject: below --
2016-03-22 17:51 Philip Oakley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56E5B27D.7010808@gmail.com \
--to=tigerkid001@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=larsxschneider@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).