On 21 Mar 2016, at 11:19, Sidhant Sharma <tigerkid...@gmail.com> wrote:
> Hi, > I updated the draft with links, ggit usage examples and some changes to the > timeline. I placed the links with reference here, but in the Google Doc, > they're > inline. > > Thanks and regards, > Sidhant Sharma > > --- > > Implement a beginner mode for Git. > > Abstract > > Git is a very powerful version control system, with an array of features > that lend the user with great capabilities. But it often so happens that some > beginners are overwhelmed by its complexity and are unable to fully understand > and thus, utilize Git. Moreover, often beginners do not fully understand > the command they are using and end up making destructive (and occasionally, > irreversible) changes to the repository. > > The beginner mode will assist such users in using Git by warning them > before making possibly destructive changes. It will also display tips and > short snippets of documentation for better understanding the Git model. > > Google summer of code Idea suggested here: > http://git.github.io/SoC-2016-Ideas/#git-beginner > > About Me > > Name : Sidhant Sharma > Email [1] : Sidhant.Sharma1208 <at> gmail.com > Email [2] : Tigerkid001 <at> gmail.com > College : Delhi Technological University > Studying : Software Engineering > IRC : tk001 (or _tk_) > Phone : 91-9990-606-081 > Country : India > Interests : Computers, Books, Photography > Github : Tigerkid001 > LinkedIn : https://in.linkedin.com/in/sidhantsharma12 > > Technical Experience > > Authored several Mozilla Firefox and Google Chrome extensions: > Firefox: Owl [1], Blink [2], Spoiler Jedi [3] > Chrome: Blink [4] > > Developed a robust Plugin framework for Android [5] for a startup. > Learning Linux kernel programming via the Eudyptula Challenge [6] > (currently level 6). > Developed natural language processor for sarcasm detection [7] in tweets. > Developed hand gesture detection module [8] as a college minor project. > Active Firefox Add-ons Editor at AMO [9]. > Currently working on a restaurant image classification project as second > college > minor project. > > Why I chose Git > > I have been using Git for about two years now, and it has become an > indispensable daily-use tool for me. Getting a chance to participate in GSoC > for the first time under Git is very exciting. It will give me an opportunity > to intimately know the system and a chance to help in making it better and > more > powerful. > > Proposal > > Ideas Page: Git Beginner [10] > > The following tasks summarize the project: > > Implement a wrapper around Git > > A wrapper is to be implemented around (currently called 'ggit'), which will > provide the following user interface: > `ggit <git-command> <options>` > For example, `ggit add --all` > The wrapper will assess the arguments passed to it, and if they are detected > to > be safe, it will simply pass them through to 'git'. This approach is > favorable as the existing > users of git will not be affected by the wrapper. > > Warning for potentially destructive commands > > For every command that is entered, the wrapper will assess the subcommand and > its options. In that, it will first check if the subcommand (eg. add, > commit, rebase) is present in a list of predefined 'potentially destructive' > commands. This can be done by searching through a radix tree for the > subcommand. > If found, then the arguments to the subcommand will be checked for specific > flags. The graylisted flags for the destructive commands will be stored as an > array of regular expressions, and the current command's arguments will be > checked against them. If matches are found, a warning is displayed. 'ggit' > for the warning would be > "You are about to do X, which will permanently destroy Y. Are you sure you > wish > to continue? [Y/n] " > If the user enters Y[es], the command will be executed as is (by passing it > unaltered to git). In the case of Y[es], 'ggit' will also give tips for > undoing > the changes made by this command (by referring the user to correct commands > and > reflog), if the command can be undone. In case the command cannot be undone, > 'ggit' will display an additional line in the warning like > "The changes made by this command cannot be undone. Please proceed > cautiously". > In the case of n[o], 'ggit' will exit without executing the command. > > Currently, the list consists of commands like: > > $ git rebase > $ git reset --hard > $ git clean -f > $ git gc --prune=now --aggressive > $ git push -f <branch> > $ git push remote [+/:]<branch> > $ git branch -D > > The list will be updated after some more discussion on the list. > > Usage tips and documentation > > The wrapper will also be responsible for showing a short description of every > command that is entered through 'ggit'. This shall be done for every command > unconditionally. The description will be derived from the actual > documentation, > but will primarily aim to help the beginner understand the Git workflow and > the > Git model. > > A few examples to illustrate the working of the wrapper are: > > $ ggit add --all > Staging all changes and untracked files. Use ` [g]git commit` to commit the > changes. > > $ ggit commit -m “Second commit” > Committing staged changes… > [master 0be3142] Second commit > 4 files changed, 6 insertions(+), 2 deletions(-) > > $ ggit reset HEAD~1 --hard > Resetting HEAD to 1 previous commit. > [WARNING] You are about to hard reset the current HEAD (master) by 1 commit. > This will take you back to commit b16aae3, and discard all changes make > thereafter. > If you want to reset but also want to retain the changes made since, use > --soft instead > of --hard. > Are you sure you want to continue? [Y/n] y > Resetting HEAD to b16aae3… > You can undo this action by resetting the HEAD to last commit you were on, > which > can be seen by running `git reflog`. ggit could know the HEAD commit here. Therefore you could suggest 'git reset --hard $HASH_OF_OLD_HEAD' in addition (I like the reference to reflog to teach users where to look for this info). > HEAD is now at b16aae3 First commit > > $ ggit push --force origin master > Pushing changes to origin/master > [WARNING] You are about to force push your history to origin/master, which > will > rewrite the remote history. Please ensure you really want to do so. I think the hardest challenge of this project is to find short and easy explanations that a newbie with almost no prior Git knowledge understands. We don't want to duplicate the man pages here. I have the impression visual explanations can often be superior. [WARNING] You are about to purge commits from the <URL of origin> master branch. State right now: o---o---o---A---B master on <URL of origin> \ X---Y---Z your master State if you continue: o---o---o---X---Y---Z master on <URL of origin> and your master Commit A and B will be gone. If other people have worked on top of A or B then they won't be able to merge their changes easily. As a bonus we could also check if the force push would actually do harm before showing the message (that means if 'git push --force' was necessary at all or if 'git push' would have done the same). Thanks, Lars > Are you sure you want to continue? [Y/n] n > Aborting push to origin/master > > Timeline > > Community Bonding Period > > Week 1 : Discuss the flow of course with the mentor. Discuss adequate data > structures and search techniques to be used. > > Week 2-3 : Discuss over an extensive list of commands that should be > classified > as destructive. Discuss appropriate short descriptions for commands. Submit > sample > patches for the same for comments and review. > > Week 4 : Discuss code structure, tests, optimization for least overhead and > other details. > > Coding Starts > > Week 1-2 : Submit code for a basic wrapper that will warn for a subset of the > potentially destructive command, and continue if the command is safe. > and this is stored as per to provide backward compatibility. > > Week 3-5 : Extend the wrapper to warn for more commands in the list, along > with > proper instructions for undoing them. Write tests for the commands supported > so far. > > Mid Term Evaluation > > Week 6-7 : Complete support for all graylisted commands with tests. > > Week 8-12: Add beginner-friendly documentation snippets to various git > commands. > > Week 13 : Final cleanup, final touches suggested by mentors and community. > > Pens Down Date > Submission of Code to GSOC > > [1]: https://addons.mozilla.org/en-US/firefox/addon/owl/ > [2]: https://addons.mozilla.org/en-US/firefox/addon/blink/ > [3]: https://addons.mozilla.org/en-US/firefox/addon/spoiler-jedi/ > [4]: > https://chrome.google.com/webstore/detail/blink-new-tab/kakaolkgegapcgdjdmlmcigejblohpkh/ > [5]: https://github.com/TigerKid001/flubbr > [6]: http://eudyptula-challenge.org/ > [7]: https://github.com/TigerKid001/Perry > [8]: https://github.com/TigerKid001/Dex > [9]: https://addons.mozilla.org/en-US/firefox/ > [10]: http://git.github.io/SoC-2016-Ideas/#git-beginner > -- 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
