{"thread":{"id":"41762","subject":"[GSOC/RFC] GSoC Proposal Draft | Git Beginner","startedAt":"2016-03-20T16:34:19Z","lastAt":"2016-03-22T09:43:07Z","messageCount":9,"participants":["Sidhant Sharma","Matthieu Moy","Lars Schneider"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"281289","messageId":"56EED10B.4010604@gmail.com","threadId":"41762","inReplyTo":null,"subject":"[GSOC/RFC] GSoC Proposal Draft | Git Beginner","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-03-20T16:34:19Z","receivedAt":"2016-03-20T16:34:19Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"Hi,\n\nI have drafted my proposal for the project 'Git Beginner', and would\nlike to request your suggestions on improving it. I'm also reading up the Git \ndocumentation and the Git ProBook (again) to make notes for the beginner\ndocumentation. Would be great to hear your comments on it.\n\nThanks and regards,\nSidhant Sharma\n\n---\n\nImplement a beginner mode for Git.\n\nAbstract\n\nGit is a very powerful version control system, with an array of features\nthat lend the user with great capabilities. But it often so happens that some\nbeginners are overwhelmed by its complexity and are unable to fully understand\nand thus, utilize Git. Moreover, often beginners do not fully understand\nthe command they are using and end up making destructive (and occasionally,\nirreversible) changes to the repository.\n\nThe beginner mode will assist such users in using Git by warning them\nbefore making possibly destructive changes. It will also display tips and\nshort snippets of documentation for better understanding the Git model.\n\nAbout Me\n\nName : Sidhant Sharma\nEmail [1] : Sidhant.Sharma1208 gmail.com\nEmail [2] : Tigerkid001 gmail.com\nCollege : Delhi Technological University\nStudying : Software Engineering\nIRC : tk001 (or _tk_)\nPhone : 91-9990-606-081\nCountry : India\nInterests : Computers, Books, Photography\nGithub : Tigerkid001\nLinkedIn : https://in.linkedin.com/in/sidhantsharma12\n\nTechnical Experience\n\nAuthored several Mozilla Firefox and Google Chrome extensions.\nDeveloped a robust Plugin framework for Android for a startup. Learning Linux\nkernel programming via the Eudyptula Challenge.\nDeveloped natural language processor for sarcasm detection in tweets.\nDeveloped gesture detection module as a college minor project.\nActive Firefox Add-ons Editor at AMO (addons mozilla org).\nCurrently working on a restaurant image classification project as second college\nminor project.\n\n\n\nWhy I chose Git\n\nI have been using Git for about two years now, and it has become an\nindispensable daily-use tool for me. Getting a chance to participate in GSoC\nfor the first time under Git is very exciting. It will give me an opportunity\nto intimately know the system and a chance to help in making it better and more\npowerful.\n\nProposal\n\nIdeas Page: Git Beginner\n\nThe following tasks summarize the project:\n\nImplement a wrapper around Git\n\nA wrapper is to be implemented around (currently called 'ggit'), which will\nprovide the following user interface:\n`ggit `\nFor example, `ggit add --all`\nThe wrapper will assess the arguments passed to it, and if they are detected to\nbe safe, it will simply pass them through to 'git'.\n\nWarning for potentially destructive commands\n\nFor every command that is entered, the wrapper will assess the subcommand and\nits options. In that, it will first check if the subcommand (eg. add,\ncommit, rebase) is present in a list of predefined 'potentially destructive'\ncommands. This can be done by searching through a radix tree for the subcommand.\nIf found, then the arguments to the subcommand will be checked for specific\nflags. The graylisted flags for the destructive commands will be stored as an\narray of regular expressions, and the current command's arguments will be\nchecked against them. If matches are found, a warning is displayed. 'ggit'\nfor the warning would be\n\"You are about to do X, which will permanently destroy Y. Are you sure you wish\nto continue? [Y/n] \"\nIf the user enters Y[es], the command will be executed as is (by passing it\nunaltered to git). In the case of Y[es], 'ggit' will also give tips for undoing\nthe changes made by this command (by referring the user to correct commands and\nreflog), if the command can be undone. In case the command cannot be undone,\n'ggit' will display an additional line in the warning like\n\"The changes made by this command cannot be undone. Please proceed cautiously\".\nIn the case of n[o], 'ggit' will exit without executing the command.\nUsage tips and documentation\n\nThe wrapper will also be responsible for showing a short description of every\ncommand that is entered through 'ggit'. This shall be done for every command\nunconditionally. The description will be derived from the actual documentation,\nbut will primarily aim to help the beginner understand the Git workflow and the\nGit model.\n\nTimeline\n\nCommunity Bonding Period\n\nWeek 1 : Discuss the flow of course with the mentor. Discuss adequate data\nstructures and search techniques to be used.\n\nWeek 2-3 : Discuss over an extensive list of commands that should be classified\nas destructive. Discuss appropriate short descriptions for commands.\n\nWeek 4 : Discuss code structure, tests, optimization for least overhead and\nother details.\n\nCoding Starts\n\nWeek 1-2 : Submit code for a basic wrapper that will warn for a subset of the\npotentially destructive command, and continue if the command is safe.\nand this is stored as per to provide backward compatibility.\n\nWeek 3-6 : Extend the wrapper to warn for all commands in the list, along with\nproper instructions for undoing them.\n\nMid Term Evaluation\n\nWeek 7-10 : Add beginner-friendly documentation snippets to various git commands.\n\nWeek 10-12 : Write tests, evaluate performance.\n\nWeek 13 : Final cleanup, final touches suggested by mentors and community.\n\nPens Down Date\nSubmission of Code to GSOC\n\n\nPost GSoC 2016\nAfter GSoC 2016 is over, I believe there will stilll be further work required\nfor improving and perfecting the 'ggit' interface before it can be merged with\nthe main distribution. I would like to continue my work on this project and\ncontribute to Git in general as well.\n"},{"id":"281303","messageId":"vpq4mc1asmy.fsf@anie.imag.fr","threadId":"41762","inReplyTo":"56EED10B.4010604@gmail.com","subject":"Re: [GSOC/RFC] GSoC Proposal Draft | Git Beginner","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-03-20T18:52:53Z","receivedAt":"2016-03-20T18:52:53Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Sidhant Sharma writes:\n\n> Implement a beginner mode for Git.\n> \n> Abstract\n> \n> Git is a very powerful version control system, with an array of features\n> that lend the user with great capabilities. But it often so happens that some\n> beginners are overwhelmed by its complexity and are unable to fully understand\n> and thus, utilize Git. Moreover, often beginners do not fully understand\n> the command they are using and end up making destructive (and occasionally,\n> irreversible) changes to the repository.\n> \n> The beginner mode will assist such users in using Git by warning them\n> before making possibly destructive changes. It will also display tips and\n> short snippets of documentation for better understanding the Git model.\n[...]\n\n(Google summer of code Idea suggested here:\nhttp://git.github.io/SoC-2016-Ideas/#git-beginner )\n\n> A wrapper is to be implemented around (currently called 'ggit'), which will\n> provide the following user interface:\n> `ggit `\n\nThere's actually already a tool doing this:\n\n https://people.gnome.org/~newren/eg/\n\nI'm Cc-ing the author.\n\nI heard good feedback about the tool in the early days of Git, when git\nitself was rather clearly not ready for bare mortals. The tool seems\nabandonned since 2013 (last release), my guess is that git became usable\nenough and eg is not needed as much as it was. For example, eg defaulted\nto push.default=tracking before we did the change to push.default=simple\nin git.\n\nI think the \"wrapper\" approach is sound. It avoids touching git itself\nand breaking things that depend on git (for example, adding\ncore.denyHardReset to let \"git reset --hard\" error out would be\nunacceptable because it would mean that any script using \"git reset\n--hard\" would break when a user has the option set in ~/.gitconfig).\n\nNote that it implies writting an almost full-blown option parser to\nrecognize commands like\n\nggit --work-tree git --namespace reset --git-dir --hard git log\n\n(just looking for \"git\", \"reset\" and \"--hard\" in the command-line would\nnot work here).\n\nAnother option would be to have a C implementation of ggit that would\nreuse the whole git source code, but set a flag \"beginner_mode\" to true\nbefore starting, and then introduce \"if (beginner_mode)\" within Git's\nsource code. I think the wrapper approach is better since it avoids\n\"polluting\" Git's source code itself.\n\n> The wrapper will assess the arguments passed to it, and if they are detected to\n> be safe, it will simply pass them through to 'git'.\n>\n> Warning for potentially destructive commands\n>\n> For every command that is entered, the wrapper will assess the subcommand and\n> its options. In that, it will first check if the subcommand (eg. add,\n> commit, rebase) is present in a list of predefined 'potentially destructive'\n> commands. This can be done by searching through a radix tree for the subcommand.\n> If found, then the arguments to the subcommand will be checked for specific\n> flags. The graylisted flags for the destructive commands will be stored as an\n> array of regular expressions, and the current command's arguments will be\n> checked against them. If matches are found, a warning is displayed. 'ggit'\n> for the warning would be\n> \"You are about to do X, which will permanently destroy Y. Are you sure you wish\n> to continue? [Y/n] \"\n> If the user enters Y[es], the command will be executed as is (by passing it\n> unaltered to git). In the case of Y[es], 'ggit' will also give tips for undoing\n> the changes made by this command (by referring the user to correct commands and\n> reflog), if the command can be undone. In case the command cannot be undone,\n> 'ggit' will display an additional line in the warning like\n> \"The changes made by this command cannot be undone. Please proceed cautiously\".\n> In the case of n[o], 'ggit' will exit without executing the command.\n> Usage tips and documentation\n>\n> The wrapper will also be responsible for showing a short description of every\n> command that is entered through 'ggit'. This shall be done for every command\n> unconditionally.\n\nI'm not 100% convinced that this is a good idea: it'd be tempting for\nthe user to run a command just to know what it does. Perhaps it's better\nto let the user run \"git -h\" instead. But it could indeed help\nfor commands doing very different things depending on the options, like\n\n$ git checkout foo\nChecks-out branch foo\n$ git checkout -b bar\nCreating a new branch bar and checking it out\n$ git checkout HEAD -- .\nReverting directory . to its last commited state\n\n...\n\n(I think a list of examples would be an important addition to your\nproposal to clarify the plans)\n\n> The description will be derived from the actual documentation, but\n> will primarily aim to help the beginner understand the Git workflow\n> and the Git model.\n>\n> Timeline\n>\n> Community Bonding Period\n>\n> Week 1 : Discuss the flow of course with the mentor. Discuss adequate data\n> structures and search techniques to be used.\n>\n> Week 2-3 : Discuss over an extensive list of commands that should be classified\n> as destructive. Discuss appropriate short descriptions for commands.\n>\n> Week 4 : Discuss code structure, tests, optimization for least overhead and\n> other details.\n>\n> Coding Starts\n>\n> Week 1-2 : Submit code for a basic wrapper that will warn for a subset of the\n> potentially destructive command, and continue if the command is safe.\n> and this is stored as per to provide backward compatibility.\n\nI think you can submit an RFC even earlier. Writting and discussing an\nextensive list of commands before seeing any code might end up being\nboring...\n\n> Week 3-6 : Extend the wrapper to warn for all commands in the list, along with\n> proper instructions for undoing them.\n>\n> Mid Term Evaluation\n>\n> Week 7-10 : Add beginner-friendly documentation snippets to various git commands.\n>\n> Week 10-12 : Write tests, evaluate performance.\n\nYou don't want to write tests at the end.\n\n> Week 13 : Final cleanup, final touches suggested by mentors and community.\n>\n> Pens Down Date\n> Submission of Code to GSOC\n>\n>\n> Post GSoC 2016\n> After GSoC 2016 is over, I believe there will stilll be further work required\n> for improving and perfecting the 'ggit' interface before it can be merged with\n> the main distribution.\n\nI think having the wrapper merged in the main distribution before the\nend of the GSoC must be a goal of the project. Sure, it can be improved\nlater, but code not merged at the end of a GSoC usually rests for months\nor years, and is often lost forever.\n\n> I would like to continue my work on this project and contribute to Git\n> in general as well.\n\nCheers,\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"281332","messageId":"56EFA558.5020301@gmail.com","threadId":"41762","inReplyTo":"vpq4mc1asmy.fsf@anie.imag.fr","subject":"Re: [GSOC/RFC] GSoC Proposal Draft | Git Beginner","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-03-21T07:40:08Z","receivedAt":"2016-03-21T07:40:08Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"\nOn Monday 21 March 2016 12:22 AM, Matthieu Moy wrote:\n> Sidhant Sharma writes:\n>\n>> A wrapper is to be implemented around (currently called 'ggit'), which will\n>> provide the following user interface:\n>> `ggit `\n> There's actually already a tool doing this:\n>\n> https://people.gnome.org/~newren/eg/\n>\n> I'm Cc-ing the author.\n>\n> I heard good feedback about the tool in the early days of Git, when git\n> itself was rather clearly not ready for bare mortals. The tool seems\n> abandonned since 2013 (last release), my guess is that git became usable\n> enough and eg is not needed as much as it was. For example, eg defaulted\n> to push.default=tracking before we did the change to push.default=simple\n> in git.\nNice! I'll take a look at its source and see how it works.\n>\n> I think the \"wrapper\" approach is sound. It avoids touching git itself\n> and breaking things that depend on git (for example, adding\n> core.denyHardReset to let \"git reset --hard\" error out would be\n> unacceptable because it would mean that any script using \"git reset\n> --hard\" would break when a user has the option set in ~/.gitconfig).\n>\n> Note that it implies writting an almost full-blown option parser to\n> recognize commands like\n>\n> ggit --work-tree git --namespace reset --git-dir --hard git log\n>\n> (just looking for \"git\", \"reset\" and \"--hard\" in the command-line would\n> not work here).\n\nCould you please elaborate on the above command, I'm unable to\nunderstand its syntax. I thought all git commands follow the\n`git command ` syntax, so using simple string\nmanipulations and regexes would work. Am I missing something?\n\n>> The wrapper will assess the arguments passed to it, and if they are detected to\n>> be safe, it will simply pass them through to 'git'.\n>>\n>> Warning for potentially destructive commands\n>>\n>> For every command that is entered, the wrapper will assess the subcommand and\n>> its options. In that, it will first check if the subcommand (eg. add,\n>> commit, rebase) is present in a list of predefined 'potentially destructive'\n>> commands. This can be done by searching through a radix tree for the subcommand.\n>> If found, then the arguments to the subcommand will be checked for specific\n>> flags. The graylisted flags for the destructive commands will be stored as an\n>> array of regular expressions, and the current command's arguments will be\n>> checked against them. If matches are found, a warning is displayed. 'ggit'\n>> for the warning would be\n>> \"You are about to do X, which will permanently destroy Y. Are you sure you wish\n>> to continue? [Y/n] \"\n>> If the user enters Y[es], the command will be executed as is (by passing it\n>> unaltered to git). In the case of Y[es], 'ggit' will also give tips for undoing\n>> the changes made by this command (by referring the user to correct commands and\n>> reflog), if the command can be undone. In case the command cannot be undone,\n>> 'ggit' will display an additional line in the warning like\n>> \"The changes made by this command cannot be undone. Please proceed cautiously\".\n>> In the case of n[o], 'ggit' will exit without executing the command.\n>> Usage tips and documentation\n>>\n>> The wrapper will also be responsible for showing a short description of every\n>> command that is entered through 'ggit'. This shall be done for every command\n>> unconditionally.\n> I'm not 100% convinced that this is a good idea: it'd be tempting for\n> the user to run a command just to know what it does. Perhaps it's better\n> to let the user run \"git -h\" instead. But it could indeed help\n> for commands doing very different things depending on the options, like\n>\n> $ git checkout foo\n> Checks-out branch foo\n> $ git checkout -b bar\n> Creating a new branch bar and checking it out\n> $ git checkout HEAD -- .\n> Reverting directory . to its last commited state\n\nYes, I did consider that and came up with this: I thought we can\nhave an option like --intro or --doc that will just print the\nintro snippet for the command without actually running. Though\n\"git -h\" is an option, I wasn't inclined towards it as I\nthink sometimes the output from -h may not make sense to a new user.\nPlus, -h only gives an elaborate list of syntax and options/arguments\nbut not say what the command does.\n\n> ...\n>\n> (I think a list of examples would be an important addition to your\n> proposal to clarify the plans)\n\nWill do that.\n\n>> The description will be derived from the actual documentation, but\n>> will primarily aim to help the beginner understand the Git workflow\n>> and the Git model.\n>>\n>> Timeline\n>>\n>> Community Bonding Period\n>>\n>> Week 1 : Discuss the flow of course with the mentor. Discuss adequate data\n>> structures and search techniques to be used.\n>>\n>> Week 2-3 : Discuss over an extensive list of commands that should be classified\n>> as destructive. Discuss appropriate short descriptions for commands.\n>>\n>> Week 4 : Discuss code structure, tests, optimization for least overhead and\n>> other details.\n>>\n>> Coding Starts\n>>\n>> Week 1-2 : Submit code for a basic wrapper that will warn for a subset of the\n>> potentially destructive command, and continue if the command is safe.\n>> and this is stored as per to provide backward compatibility.\n> I think you can submit an RFC even earlier. Writting and discussing an\n> extensive list of commands before seeing any code might end up being\n> boring...\n\nI wasn't sure if we are allowed to code before the actual coding period begins\nso I kept it that way. I'll update it now.\n\n>> Week 3-6 : Extend the wrapper to warn for all commands in the list, along with\n>> proper instructions for undoing them.\n>>\n>> Mid Term Evaluation\n>>\n>> Week 7-10 : Add beginner-friendly documentation snippets to various git commands.\n>>\n>> Week 10-12 : Write tests, evaluate performance.\n> You don't want to write tests at the end.\n>\nAlright, I'll put writing tests into their respective time frames.\n>> Week 13 : Final cleanup, final touches suggested by mentors and community.\n>>\n>> Pens Down Date\n>> Submission of Code to GSOC\n>>\n>>\n>> Post GSoC 2016\n>> After GSoC 2016 is over, I believe there will stilll be further work required\n>> for improving and perfecting the 'ggit' interface before it can be merged with\n>> the main distribution.\n> I think having the wrapper merged in the main distribution before the\n> end of the GSoC must be a goal of the project. Sure, it can be improved\n> later, but code not merged at the end of a GSoC usually rests for months\n> or years, and is often lost forever.\n\nOK, so I guess that section can be removed altogether since it's not\nrelevant to the project otherwise.\n\n>> I would like to continue my work on this project and contribute to Git\n>> in general as well.\n> Cheers,\n\nThanks and regards,\nSidhant\n"},{"id":"281334","messageId":"vpqd1qo5j5e.fsf@anie.imag.fr","threadId":"41762","inReplyTo":"56EFA558.5020301@gmail.com","subject":"Re: [GSOC/RFC] GSoC Proposal Draft | Git Beginner","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-03-21T08:29:01Z","receivedAt":"2016-03-21T08:29:01Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Sidhant Sharma writes:\n\n> On Monday 21 March 2016 12:22 AM, Matthieu Moy wrote:\n>\n>> Note that it implies writting an almost full-blown option parser to\n>> recognize commands like\n>>\n>> ggit --work-tree git --namespace reset --git-dir --hard git log\n>>\n>> (just looking for \"git\", \"reset\" and \"--hard\" in the command-line would\n>> not work here).\n>\n> Could you please elaborate on the above command, I'm unable to\n> understand its syntax. I thought all git commands follow the\n> `git command ` syntax, so using simple string\n> manipulations and regexes would work. Am I missing something?\n\nThe full syntax is\n\ngit [global options] [options and arguments for a command]\n\nFor example:\n\ngit -p log => -p is the option for \"git\" itself, which means \"paginate\"\ngit log -p => -p is the option for \"git log\", which means \"patch\"\n\nOptions can have stuck or non-stuck form, for example\n\ngit --work-tree=foo <=> git --work-tree foo\n\ngit --work-tree git --namespace reset --git-dir --hard git log\n<=>\ngit --work-tree=git --namespace=reset --git-dir=--hard git log\n\n(This is probably a stupid command to type, but it's legal)\n\nThe later is source of issues for a parser since you can't just iterate\nthrough argv[] and search for problematic commands/options, since you\nhave to distinguish options themselves (--work-tree above) and option\narguments (foo above).\n\nIn my example above, I played with global options (before \"git\" in the\ncommand-line), but I could also have done that with per-command options\ntaking arguments, like\n\ngit push --repo --force\n\nHere, --force is the name of the repo (again, probably a stupid name,\nbut why not), not the --force option.\n\n> I wasn't sure if we are allowed to code before the actual coding period begins\n> so I kept it that way. I'll update it now.\n\nYou're not \"forced\" to, but you can write code whenever you like. We've\nalready seen code written before the application!\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"281338","messageId":"56EFC8AE.3030606@gmail.com","threadId":"41762","inReplyTo":"vpqd1qo5j5e.fsf@anie.imag.fr","subject":"Re: [GSOC/RFC] GSoC Proposal Draft | Git Beginner","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-03-21T10:10:54Z","receivedAt":"2016-03-21T10:10:54Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"\n\nOn Monday 21 March 2016 01:59 PM, Matthieu Moy wrote:\n> Sidhant Sharma writes:\n>\n>> On Monday 21 March 2016 12:22 AM, Matthieu Moy wrote:\n>>\n>>> Note that it implies writting an almost full-blown option parser to\n>>> recognize commands like\n>>>\n>>> ggit --work-tree git --namespace reset --git-dir --hard git log\n>>>\n>>> (just looking for \"git\", \"reset\" and \"--hard\" in the command-line would\n>>> not work here).\n>> Could you please elaborate on the above command, I'm unable to\n>> understand its syntax. I thought all git commands follow the\n>> `git command ` syntax, so using simple string\n>> manipulations and regexes would work. Am I missing something?\n> The full syntax is\n>\n> git [global options] [options and arguments for a command]\n>\n> For example:\n>\n> git -p log => -p is the option for \"git\" itself, which means \"paginate\"\n> git log -p => -p is the option for \"git log\", which means \"patch\"\n>\n> Options can have stuck or non-stuck form, for example\n>\n> git --work-tree=foo <=> git --work-tree foo\n>\n> git --work-tree git --namespace reset --git-dir --hard git log\n> <=>\n> git --work-tree=git --namespace=reset --git-dir=--hard git log\n>\n> (This is probably a stupid command to type, but it's legal)\n>\n> The later is source of issues for a parser since you can't just iterate\n> through argv[] and search for problematic commands/options, since you\n> have to distinguish options themselves (--work-tree above) and option\n> arguments (foo above).\nThanks for the explanation; I knew of the global options but didn't know\nthat the last command would be syntactically legal. For commands like such\niterating over argv[] wouldn't work (not in all cases). Though a beginner\nmay not enter commands of this sort, I agree we shouldn't rely on that. If\nit were only for stuck commands, regexes would've worked.\nI can now see why a parser would be needed here, which can recognize global\noptions and the above command syntax. But for this example,\n> In my example above, I played with global options (before \"git\" in the\n> command-line), but I could also have done that with per-command options\n> taking arguments, like\n>\n> git push --repo --force\n>\n> Here, --force is the name of the repo (again, probably a stupid name,\n> but why not), not the --force option.\nwould the parser also be required to understand all options and arguments for\nall git commands? Although --force could not be a branch name (git denies it),\nbut it may not be so for other commands.\n>> I wasn't sure if we are allowed to code before the actual coding period begins\n>> so I kept it that way. I'll update it now.\n> You're not \"forced\" to, but you can write code whenever you like. We've\n> already seen code written before the application!\n>\nNice! I too would like to get started early :)\n"},{"id":"281339","messageId":"56EFCAB2.2090804@gmail.com","threadId":"41762","inReplyTo":"vpq4mc1asmy.fsf@anie.imag.fr","subject":"Re: [GSOC/RFC] GSoC Proposal Draft | Git Beginner","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-03-21T10:19:30Z","receivedAt":"2016-03-21T10:19:30Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"Hi,\nI updated the draft with links, ggit usage examples and some changes to the\ntimeline. I placed the links with reference here, but in the Google Doc, they're\ninline.\n\nThanks and regards,\nSidhant Sharma\n\n---\n\nImplement a beginner mode for Git.\n\nAbstract\n\nGit is a very powerful version control system, with an array of features\nthat lend the user with great capabilities. But it often so happens that some\nbeginners are overwhelmed by its complexity and are unable to fully understand\nand thus, utilize Git. Moreover, often beginners do not fully understand\nthe command they are using and end up making destructive (and occasionally,\nirreversible) changes to the repository.\n\nThe beginner mode will assist such users in using Git by warning them\nbefore making possibly destructive changes. It will also display tips and\nshort snippets of documentation for better understanding the Git model.\n\nGoogle summer of code Idea suggested here:\nhttp://git.github.io/SoC-2016-Ideas/#git-beginner\n\nAbout Me\n\nName : Sidhant Sharma\nEmail [1] : Sidhant.Sharma1208 gmail.com\nEmail [2] : Tigerkid001 gmail.com\nCollege : Delhi Technological University\nStudying : Software Engineering\nIRC : tk001 (or _tk_)\nPhone : 91-9990-606-081\nCountry : India\nInterests : Computers, Books, Photography\nGithub : Tigerkid001\nLinkedIn : https://in.linkedin.com/in/sidhantsharma12\n\nTechnical Experience\n\nAuthored several Mozilla Firefox and Google Chrome extensions:\nFirefox: Owl [1], Blink [2], Spoiler Jedi [3]\nChrome: Blink [4]\n\nDeveloped a robust Plugin framework for Android [5] for a startup.\nLearning Linux kernel programming via the Eudyptula Challenge [6]\n(currently level 6).\nDeveloped natural language processor for sarcasm detection [7] in tweets.\nDeveloped hand gesture detection module [8] as a college minor project.\nActive Firefox Add-ons Editor at AMO [9].\nCurrently working on a restaurant image classification project as second college\nminor project.\n\nWhy I chose Git\n\nI have been using Git for about two years now, and it has become an\nindispensable daily-use tool for me. Getting a chance to participate in GSoC\nfor the first time under Git is very exciting. It will give me an opportunity\nto intimately know the system and a chance to help in making it better and more\npowerful.\n\nProposal\n\nIdeas Page: Git Beginner [10]\n\nThe following tasks summarize the project:\n\nImplement a wrapper around Git\n\nA wrapper is to be implemented around (currently called 'ggit'), which will\nprovide the following user interface:\n`ggit `\nFor example, `ggit add --all`\nThe wrapper will assess the arguments passed to it, and if they are detected to\nbe safe, it will simply pass them through to 'git'. This approach is favorable as the existing\nusers of git will not be affected by the wrapper.\n\nWarning for potentially destructive commands\n\nFor every command that is entered, the wrapper will assess the subcommand and\nits options. In that, it will first check if the subcommand (eg. add,\ncommit, rebase) is present in a list of predefined 'potentially destructive'\ncommands. This can be done by searching through a radix tree for the subcommand.\nIf found, then the arguments to the subcommand will be checked for specific\nflags. The graylisted flags for the destructive commands will be stored as an\narray of regular expressions, and the current command's arguments will be\nchecked against them. If matches are found, a warning is displayed. 'ggit'\nfor the warning would be\n\"You are about to do X, which will permanently destroy Y. Are you sure you wish\nto continue? [Y/n] \"\nIf the user enters Y[es], the command will be executed as is (by passing it\nunaltered to git). In the case of Y[es], 'ggit' will also give tips for undoing\nthe changes made by this command (by referring the user to correct commands and\nreflog), if the command can be undone. In case the command cannot be undone,\n'ggit' will display an additional line in the warning like\n\"The changes made by this command cannot be undone. Please proceed cautiously\".\nIn the case of n[o], 'ggit' will exit without executing the command.\n\nCurrently, the list consists of commands like:\n\n$ git rebase\n$ git reset --hard\n$ git clean -f\n$ git gc --prune=now --aggressive\n$ git push -f \n$ git push remote [+/:]\n$ git branch -D\n\nThe list will be updated after some more discussion on the list.\n\nUsage tips and documentation\n\nThe wrapper will also be responsible for showing a short description of every\ncommand that is entered through 'ggit'. This shall be done for every command\nunconditionally. The description will be derived from the actual documentation,\nbut will primarily aim to help the beginner understand the Git workflow and the\nGit model.\n\nA few examples to illustrate the working of the wrapper are:\n\n$ ggit add --all\nStaging all changes and untracked files. Use ` [g]git commit` to commit the changes.\n\n$ ggit commit -m “Second commit”\nCommitting staged changes…\n[master 0be3142] Second commit\n 4 files changed, 6 insertions(+), 2 deletions(-)\n\n$ ggit reset HEAD~1 --hard\nResetting HEAD to 1 previous commit.\n[WARNING] You are about to hard reset the current HEAD (master) by 1 commit.\nThis will take you back to commit b16aae3, and discard all changes make thereafter.\nIf you want to reset but also want to retain the changes made since, use --soft instead\nof --hard.\nAre you sure you want to continue? [Y/n] y\nResetting HEAD to b16aae3…\nYou can undo this action by resetting the HEAD to last commit you were on, which\ncan be seen by running `git reflog`.\nHEAD is now at b16aae3 First commit\n\n$ ggit push --force origin master\nPushing changes to origin/master\n[WARNING] You are about to force push your history to origin/master, which will\nrewrite the remote history. Please ensure you really want to do so.\nAre you sure you want to continue? [Y/n] n\nAborting push to origin/master\n\nTimeline\n\nCommunity Bonding Period\n\nWeek 1 : Discuss the flow of course with the mentor. Discuss adequate data\nstructures and search techniques to be used.\n\nWeek 2-3 : Discuss over an extensive list of commands that should be classified\nas destructive. Discuss appropriate short descriptions for commands. Submit sample\npatches for the same for comments and review.\n\nWeek 4 : Discuss code structure, tests, optimization for least overhead and\nother details.\n\nCoding Starts\n\nWeek 1-2 : Submit code for a basic wrapper that will warn for a subset of the\npotentially destructive command, and continue if the command is safe.\nand this is stored as per to provide backward compatibility.\n\nWeek 3-5 : Extend the wrapper to warn for more commands in the list, along with\nproper instructions for undoing them. Write tests for the commands supported so far.\n\nMid Term Evaluation\n\nWeek 6-7 : Complete support for all graylisted commands with tests.\n\nWeek 8-12: Add beginner-friendly documentation snippets to various git commands.\n\nWeek 13 : Final cleanup, final touches suggested by mentors and community.\n\nPens Down Date\nSubmission of Code to GSOC\n\n[1]: https://addons.mozilla.org/en-US/firefox/addon/owl/\n[2]: https://addons.mozilla.org/en-US/firefox/addon/blink/\n[3]: https://addons.mozilla.org/en-US/firefox/addon/spoiler-jedi/\n[4]: https://chrome.google.com/webstore/detail/blink-new-tab/kakaolkgegapcgdjdmlmcigejblohpkh/\n[5]: https://github.com/TigerKid001/flubbr\n[6]: http://eudyptula-challenge.org/\n[7]: https://github.com/TigerKid001/Perry\n[8]: https://github.com/TigerKid001/Dex\n[9]: https://addons.mozilla.org/en-US/firefox/\n[10]: http://git.github.io/SoC-2016-Ideas/#git-beginner\n"},{"id":"281419","messageId":"6ACB21B7-060F-4E22-BCA3-04A0341A1BC5@gmail.com","threadId":"41762","inReplyTo":"56EFCAB2.2090804@gmail.com","subject":"Re: [GSOC/RFC] GSoC Proposal Draft | Git Beginner","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-03-22T08:38:02Z","receivedAt":"2016-03-22T08:38:02Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\nOn 21 Mar 2016, at 11:19, Sidhant Sharma wrote:\n\n> Hi,\n> I updated the draft with links, ggit usage examples and some changes to the\n> timeline. I placed the links with reference here, but in the Google Doc, they're\n> inline.\n> \n> Thanks and regards,\n> Sidhant Sharma\n> \n> ---\n> \n> Implement a beginner mode for Git.\n> \n> Abstract\n> \n> Git is a very powerful version control system, with an array of features\n> that lend the user with great capabilities. But it often so happens that some\n> beginners are overwhelmed by its complexity and are unable to fully understand\n> and thus, utilize Git. Moreover, often beginners do not fully understand\n> the command they are using and end up making destructive (and occasionally,\n> irreversible) changes to the repository.\n> \n> The beginner mode will assist such users in using Git by warning them\n> before making possibly destructive changes. It will also display tips and\n> short snippets of documentation for better understanding the Git model.\n> \n> Google summer of code Idea suggested here:\n> http://git.github.io/SoC-2016-Ideas/#git-beginner\n> \n> About Me\n> \n> Name : Sidhant Sharma\n> Email [1] : Sidhant.Sharma1208 gmail.com\n> Email [2] : Tigerkid001 gmail.com\n> College : Delhi Technological University\n> Studying : Software Engineering\n> IRC : tk001 (or _tk_)\n> Phone : 91-9990-606-081\n> Country : India\n> Interests : Computers, Books, Photography\n> Github : Tigerkid001\n> LinkedIn : https://in.linkedin.com/in/sidhantsharma12\n> \n> Technical Experience\n> \n> Authored several Mozilla Firefox and Google Chrome extensions:\n> Firefox: Owl [1], Blink [2], Spoiler Jedi [3]\n> Chrome: Blink [4]\n> \n> Developed a robust Plugin framework for Android [5] for a startup.\n> Learning Linux kernel programming via the Eudyptula Challenge [6]\n> (currently level 6).\n> Developed natural language processor for sarcasm detection [7] in tweets.\n> Developed hand gesture detection module [8] as a college minor project.\n> Active Firefox Add-ons Editor at AMO [9].\n> Currently working on a restaurant image classification project as second college\n> minor project.\n> \n> Why I chose Git\n> \n> I have been using Git for about two years now, and it has become an\n> indispensable daily-use tool for me. Getting a chance to participate in GSoC\n> for the first time under Git is very exciting. It will give me an opportunity\n> to intimately know the system and a chance to help in making it better and more\n> powerful.\n> \n> Proposal\n> \n> Ideas Page: Git Beginner [10]\n> \n> The following tasks summarize the project:\n> \n> Implement a wrapper around Git\n> \n> A wrapper is to be implemented around (currently called 'ggit'), which will\n> provide the following user interface:\n> `ggit `\n> For example, `ggit add --all`\n> The wrapper will assess the arguments passed to it, and if they are detected to\n> be safe, it will simply pass them through to 'git'. This approach is favorable as the existing\n> users of git will not be affected by the wrapper.\n> \n> Warning for potentially destructive commands\n> \n> For every command that is entered, the wrapper will assess the subcommand and\n> its options. In that, it will first check if the subcommand (eg. add,\n> commit, rebase) is present in a list of predefined 'potentially destructive'\n> commands. This can be done by searching through a radix tree for the subcommand.\n> If found, then the arguments to the subcommand will be checked for specific\n> flags. The graylisted flags for the destructive commands will be stored as an\n> array of regular expressions, and the current command's arguments will be\n> checked against them. If matches are found, a warning is displayed. 'ggit'\n> for the warning would be\n> \"You are about to do X, which will permanently destroy Y. Are you sure you wish\n> to continue? [Y/n] \"\n> If the user enters Y[es], the command will be executed as is (by passing it\n> unaltered to git). In the case of Y[es], 'ggit' will also give tips for undoing\n> the changes made by this command (by referring the user to correct commands and\n> reflog), if the command can be undone. In case the command cannot be undone,\n> 'ggit' will display an additional line in the warning like\n> \"The changes made by this command cannot be undone. Please proceed cautiously\".\n> In the case of n[o], 'ggit' will exit without executing the command.\n> \n> Currently, the list consists of commands like:\n> \n> $ git rebase\n> $ git reset --hard\n> $ git clean -f\n> $ git gc --prune=now --aggressive\n> $ git push -f \n> $ git push remote [+/:]\n> $ git branch -D\n> \n> The list will be updated after some more discussion on the list.\n> \n> Usage tips and documentation\n> \n> The wrapper will also be responsible for showing a short description of every\n> command that is entered through 'ggit'. This shall be done for every command\n> unconditionally. The description will be derived from the actual documentation,\n> but will primarily aim to help the beginner understand the Git workflow and the\n> Git model.\n> \n> A few examples to illustrate the working of the wrapper are:\n> \n> $ ggit add --all\n> Staging all changes and untracked files. Use ` [g]git commit` to commit the changes.\n> \n> $ ggit commit -m “Second commit”\n> Committing staged changes…\n> [master 0be3142] Second commit\n> 4 files changed, 6 insertions(+), 2 deletions(-)\n> \n> $ ggit reset HEAD~1 --hard\n> Resetting HEAD to 1 previous commit.\n> [WARNING] You are about to hard reset the current HEAD (master) by 1 commit.\n> This will take you back to commit b16aae3, and discard all changes make thereafter.\n> If you want to reset but also want to retain the changes made since, use --soft instead\n> of --hard.\n> Are you sure you want to continue? [Y/n] y\n> Resetting HEAD to b16aae3…\n> You can undo this action by resetting the HEAD to last commit you were on, which\n> can be seen by running `git reflog`.\nggit could know the HEAD commit here. Therefore you could suggest 'git reset --hard $HASH_OF_OLD_HEAD'\nin addition (I like the reference to reflog to teach users where to look for this info).\n\n\n> HEAD is now at b16aae3 First commit\n> \n> $ ggit push --force origin master\n> Pushing changes to origin/master\n> [WARNING] You are about to force push your history to origin/master, which will\n> rewrite the remote history. Please ensure you really want to do so.\nI think the hardest challenge of this project is to find short and easy\nexplanations that a newbie with almost no prior Git knowledge understands. \nWe don't want to duplicate the man pages here. I have the impression visual \nexplanations can often be superior.\n\n\n[WARNING] You are about to purge commits from the master branch. \n\nState right now:\n\t o---o---o---A---B master on \n\t\t \\\n\t\t X---Y---Z your master\n\nState if you continue:\n\t o---o---o---X---Y---Z master on and your master\n\nCommit A and B will be gone. If other people have worked on top of A or B then\nthey won't be able to merge their changes easily.\n\nAs a bonus we could also check if the force push would actually do harm before\nshowing the message (that means if 'git push --force' was necessary at all or\nif 'git push' would have done the same).\n\n\nThanks,\nLars\n\n\n\n> Are you sure you want to continue? [Y/n] n\n> Aborting push to origin/master\n> \n> Timeline\n> \n> Community Bonding Period\n> \n> Week 1 : Discuss the flow of course with the mentor. Discuss adequate data\n> structures and search techniques to be used.\n> \n> Week 2-3 : Discuss over an extensive list of commands that should be classified\n> as destructive. Discuss appropriate short descriptions for commands. Submit sample\n> patches for the same for comments and review.\n> \n> Week 4 : Discuss code structure, tests, optimization for least overhead and\n> other details.\n> \n> Coding Starts\n> \n> Week 1-2 : Submit code for a basic wrapper that will warn for a subset of the\n> potentially destructive command, and continue if the command is safe.\n> and this is stored as per to provide backward compatibility.\n> \n> Week 3-5 : Extend the wrapper to warn for more commands in the list, along with\n> proper instructions for undoing them. Write tests for the commands supported so far.\n> \n> Mid Term Evaluation\n> \n> Week 6-7 : Complete support for all graylisted commands with tests.\n> \n> Week 8-12: Add beginner-friendly documentation snippets to various git commands.\n> \n> Week 13 : Final cleanup, final touches suggested by mentors and community.\n> \n> Pens Down Date\n> Submission of Code to GSOC\n> \n> [1]: https://addons.mozilla.org/en-US/firefox/addon/owl/\n> [2]: https://addons.mozilla.org/en-US/firefox/addon/blink/\n> [3]: https://addons.mozilla.org/en-US/firefox/addon/spoiler-jedi/\n> [4]: https://chrome.google.com/webstore/detail/blink-new-tab/kakaolkgegapcgdjdmlmcigejblohpkh/\n> [5]: https://github.com/TigerKid001/flubbr\n> [6]: http://eudyptula-challenge.org/\n> [7]: https://github.com/TigerKid001/Perry\n> [8]: https://github.com/TigerKid001/Dex\n> [9]: https://addons.mozilla.org/en-US/firefox/\n> [10]: http://git.github.io/SoC-2016-Ideas/#git-beginner\n> \n"},{"id":"281421","messageId":"56F10AC9.4050000@gmail.com","threadId":"41762","inReplyTo":"6ACB21B7-060F-4E22-BCA3-04A0341A1BC5@gmail.com","subject":"Re: [GSOC/RFC] GSoC Proposal Draft | Git Beginner","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-03-22T09:05:13Z","receivedAt":"2016-03-22T09:05:13Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"\nOn Tuesday 22 March 2016 02:08 PM, Lars Schneider wrote:\n> On 21 Mar 2016, at 11:19, Sidhant Sharma wrote:\n>\n>> Hi,\n>> I updated the draft with links, ggit usage examples and some changes to the\n>> timeline. I placed the links with reference here, but in the Google Doc, they're\n>> inline.\n>>\n>> Thanks and regards,\n>> Sidhant Sharma\n>>\n>> ---\n>>\n>> Implement a beginner mode for Git.\n>>\n>> Abstract\n>>\n>> Git is a very powerful version control system, with an array of features\n>> that lend the user with great capabilities. But it often so happens that some\n>> beginners are overwhelmed by its complexity and are unable to fully understand\n>> and thus, utilize Git. Moreover, often beginners do not fully understand\n>> the command they are using and end up making destructive (and occasionally,\n>> irreversible) changes to the repository.\n>>\n>> The beginner mode will assist such users in using Git by warning them\n>> before making possibly destructive changes. It will also display tips and\n>> short snippets of documentation for better understanding the Git model.\n>>\n>> Google summer of code Idea suggested here:\n>> http://git.github.io/SoC-2016-Ideas/#git-beginner\n>>\n>> About Me\n>>\n>> Name : Sidhant Sharma\n>> Email [1] : Sidhant.Sharma1208 gmail.com\n>> Email [2] : Tigerkid001 gmail.com\n>> College : Delhi Technological University\n>> Studying : Software Engineering\n>> IRC : tk001 (or _tk_)\n>> Phone : 91-9990-606-081\n>> Country : India\n>> Interests : Computers, Books, Photography\n>> Github : Tigerkid001\n>> LinkedIn : https://in.linkedin.com/in/sidhantsharma12\n>>\n>> Technical Experience\n>>\n>> Authored several Mozilla Firefox and Google Chrome extensions:\n>> Firefox: Owl [1], Blink [2], Spoiler Jedi [3]\n>> Chrome: Blink [4]\n>>\n>> Developed a robust Plugin framework for Android [5] for a startup.\n>> Learning Linux kernel programming via the Eudyptula Challenge [6]\n>> (currently level 6).\n>> Developed natural language processor for sarcasm detection [7] in tweets.\n>> Developed hand gesture detection module [8] as a college minor project.\n>> Active Firefox Add-ons Editor at AMO [9].\n>> Currently working on a restaurant image classification project as second college\n>> minor project.\n>>\n>> Why I chose Git\n>>\n>> I have been using Git for about two years now, and it has become an\n>> indispensable daily-use tool for me. Getting a chance to participate in GSoC\n>> for the first time under Git is very exciting. It will give me an opportunity\n>> to intimately know the system and a chance to help in making it better and more\n>> powerful.\n>>\n>> Proposal\n>>\n>> Ideas Page: Git Beginner [10]\n>>\n>> The following tasks summarize the project:\n>>\n>> Implement a wrapper around Git\n>>\n>> A wrapper is to be implemented around (currently called 'ggit'), which will\n>> provide the following user interface:\n>> `ggit `\n>> For example, `ggit add --all`\n>> The wrapper will assess the arguments passed to it, and if they are detected to\n>> be safe, it will simply pass them through to 'git'. This approach is favorable as the existing\n>> users of git will not be affected by the wrapper.\n>>\n>> Warning for potentially destructive commands\n>>\n>> For every command that is entered, the wrapper will assess the subcommand and\n>> its options. In that, it will first check if the subcommand (eg. add,\n>> commit, rebase) is present in a list of predefined 'potentially destructive'\n>> commands. This can be done by searching through a radix tree for the subcommand.\n>> If found, then the arguments to the subcommand will be checked for specific\n>> flags. The graylisted flags for the destructive commands will be stored as an\n>> array of regular expressions, and the current command's arguments will be\n>> checked against them. If matches are found, a warning is displayed. 'ggit'\n>> for the warning would be\n>> \"You are about to do X, which will permanently destroy Y. Are you sure you wish\n>> to continue? [Y/n] \"\n>> If the user enters Y[es], the command will be executed as is (by passing it\n>> unaltered to git). In the case of Y[es], 'ggit' will also give tips for undoing\n>> the changes made by this command (by referring the user to correct commands and\n>> reflog), if the command can be undone. In case the command cannot be undone,\n>> 'ggit' will display an additional line in the warning like\n>> \"The changes made by this command cannot be undone. Please proceed cautiously\".\n>> In the case of n[o], 'ggit' will exit without executing the command.\n>>\n>> Currently, the list consists of commands like:\n>>\n>> $ git rebase\n>> $ git reset --hard\n>> $ git clean -f\n>> $ git gc --prune=now --aggressive\n>> $ git push -f \n>> $ git push remote [+/:]\n>> $ git branch -D\n>>\n>> The list will be updated after some more discussion on the list.\n>>\n>> Usage tips and documentation\n>>\n>> The wrapper will also be responsible for showing a short description of every\n>> command that is entered through 'ggit'. This shall be done for every command\n>> unconditionally. The description will be derived from the actual documentation,\n>> but will primarily aim to help the beginner understand the Git workflow and the\n>> Git model.\n>>\n>> A few examples to illustrate the working of the wrapper are:\n>>\n>> $ ggit add --all\n>> Staging all changes and untracked files. Use ` [g]git commit` to commit the changes.\n>>\n>> $ ggit commit -m “Second commit”\n>> Committing staged changes…\n>> [master 0be3142] Second commit\n>> 4 files changed, 6 insertions(+), 2 deletions(-)\n>>\n>> $ ggit reset HEAD~1 --hard\n>> Resetting HEAD to 1 previous commit.\n>> [WARNING] You are about to hard reset the current HEAD (master) by 1 commit.\n>> This will take you back to commit b16aae3, and discard all changes make thereafter.\n>> If you want to reset but also want to retain the changes made since, use --soft instead\n>> of --hard.\n>> Are you sure you want to continue? [Y/n] y\n>> Resetting HEAD to b16aae3…\n>> You can undo this action by resetting the HEAD to last commit you were on, which\n>> can be seen by running `git reflog`.\n> ggit could know the HEAD commit here. Therefore you could suggest 'git reset --hard $HASH_OF_OLD_HEAD'\n> in addition (I like the reference to reflog to teach users where to look for this info).\n>\nYeah, we can put that along with the reference to reflog so it's easier for users\nto undo quickly. Will update the proposal.\n>> HEAD is now at b16aae3 First commit\n>>\n>> $ ggit push --force origin master\n>> Pushing changes to origin/master\n>> [WARNING] You are about to force push your history to origin/master, which will\n>> rewrite the remote history. Please ensure you really want to do so.\n> I think the hardest challenge of this project is to find short and easy\n> explanations that a newbie with almost no prior Git knowledge understands. \n> We don't want to duplicate the man pages here. I have the impression visual \n> explanations can often be superior.\n>\n>\n> [WARNING] You are about to purge commits from the master branch. \n>\n> State right now:\n> \t o---o---o---A---B master on \n> \t\t \\\n> \t\t X---Y---Z your master\n>\n> State if you continue:\n> \t o---o---o---X---Y---Z master on and your master\n>\n> Commit A and B will be gone. If other people have worked on top of A or B then\n> they won't be able to merge their changes easily.\nI totally agree that visuals would serve the purpose much better. I'll\nupdate the example with the warning message you suggest, and get started\nwith preparing more such visual descriptions. I'll post them for RFC soon.\n> As a bonus we could also check if the force push would actually do harm before\n> showing the message (that means if 'git push --force' was necessary at all or\n> if 'git push' would have done the same).\nThat'll be a nice touch. Will keep that in mind.\n\n\nThanks and regards,\nSidhant Sharma\n>\n> Thanks,\n> Lars\n>\n>\n>\n>> Are you sure you want to continue? [Y/n] n\n>> Aborting push to origin/master\n>>\n>> Timeline\n>>\n>> Community Bonding Period\n>>\n>> Week 1 : Discuss the flow of course with the mentor. Discuss adequate data\n>> structures and search techniques to be used.\n>>\n>> Week 2-3 : Discuss over an extensive list of commands that should be classified\n>> as destructive. Discuss appropriate short descriptions for commands. Submit sample\n>> patches for the same for comments and review.\n>>\n>> Week 4 : Discuss code structure, tests, optimization for least overhead and\n>> other details.\n>>\n>> Coding Starts\n>>\n>> Week 1-2 : Submit code for a basic wrapper that will warn for a subset of the\n>> potentially destructive command, and continue if the command is safe.\n>> and this is stored as per to provide backward compatibility.\n>>\n>> Week 3-5 : Extend the wrapper to warn for more commands in the list, along with\n>> proper instructions for undoing them. Write tests for the commands supported so far.\n>>\n>> Mid Term Evaluation\n>>\n>> Week 6-7 : Complete support for all graylisted commands with tests.\n>>\n>> Week 8-12: Add beginner-friendly documentation snippets to various git commands.\n>>\n>> Week 13 : Final cleanup, final touches suggested by mentors and community.\n>>\n>> Pens Down Date\n>> Submission of Code to GSOC\n>>\n>> [1]: https://addons.mozilla.org/en-US/firefox/addon/owl/\n>> [2]: https://addons.mozilla.org/en-US/firefox/addon/blink/\n>> [3]: https://addons.mozilla.org/en-US/firefox/addon/spoiler-jedi/\n>> [4]: https://chrome.google.com/webstore/detail/blink-new-tab/kakaolkgegapcgdjdmlmcigejblohpkh/\n>> [5]: https://github.com/TigerKid001/flubbr\n>> [6]: http://eudyptula-challenge.org/\n>> [7]: https://github.com/TigerKid001/Perry\n>> [8]: https://github.com/TigerKid001/Dex\n>> [9]: https://addons.mozilla.org/en-US/firefox/\n>> [10]: http://git.github.io/SoC-2016-Ideas/#git-beginner\n>>\n"},{"id":"281423","messageId":"56F113AB.8010606@gmail.com","threadId":"41762","inReplyTo":"6ACB21B7-060F-4E22-BCA3-04A0341A1BC5@gmail.com","subject":"Re: [GSOC/RFC] GSoC Proposal Draft | Git Beginner","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-03-22T09:43:07Z","receivedAt":"2016-03-22T09:43:07Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"Updated examples with better description for force push and reset HEAD, as\nsuggested by Lars [11].\n\nThanks and regards,\nSidhant Sharma\n\n[11]: http://thread.gmane.org/gmane.comp.version-control.git/289365/focus=289495\n\n---\n\nImplement a beginner mode for Git.\n\nAbstract\n\nGit is a very powerful version control system, with an array of features\nthat lend the user with great capabilities. But it often so happens that some\nbeginners are overwhelmed by its complexity and are unable to fully understand\nand thus, utilize Git. Moreover, often beginners do not fully understand\nthe command they are using and end up making destructive (and occasionally,\nirreversible) changes to the repository.\n\nThe beginner mode will assist such users in using Git by warning them\nbefore making possibly destructive changes. It will also display tips and\nshort snippets of documentation for better understanding the Git model.\n\nGoogle summer of code Idea suggested here:\nhttp://git.github.io/SoC-2016-Ideas/#git-beginner\n\nAbout Me\n\nName : Sidhant Sharma\nEmail [1] : Sidhant.Sharma1208 gmail.com\nEmail [2] : Tigerkid001 gmail.com\nCollege : Delhi Technological University\nStudying : Software Engineering\nIRC : tk001 (or _tk_)\nPhone : 91-9990-606-081\nCountry : India\nInterests : Computers, Books, Photography\nGithub : Tigerkid001\nLinkedIn : https://in.linkedin.com/in/sidhantsharma12\n\nTechnical Experience\n\nAuthored several Mozilla Firefox and Google Chrome extensions:\nFirefox: Owl [1], Blink [2], Spoiler Jedi [3]\nChrome: Blink [4]\n\nDeveloped a robust Plugin framework for Android [5] for a startup.\nLearning Linux kernel programming via the Eudyptula Challenge [6]\n(currently level 6).\nDeveloped natural language processor for sarcasm detection [7] in tweets.\nDeveloped hand gesture detection module [8] as a college minor project.\nActive Firefox Add-ons Editor at AMO [9].\nCurrently working on a restaurant image classification project as second college\nminor project.\n\nWhy I chose Git\n\nI have been using Git for about two years now, and it has become an\nindispensable daily-use tool for me. Getting a chance to participate in GSoC\nfor the first time under Git is very exciting. It will give me an opportunity\nto intimately know the system and a chance to help in making it better and more\npowerful.\n\nProposal\n\nIdeas Page: Git Beginner [10]\n\nThe following tasks summarize the project:\n\nImplement a wrapper around Git\n\nA wrapper is to be implemented around (currently called 'ggit'), which will\nprovide the following user interface:\n`ggit `\nFor example, `ggit add --all`\nThe wrapper will assess the arguments passed to it, and if they are detected to\nbe safe, it will simply pass them through to 'git'. This approach is favorable\nas the existing users of git will not be affected by the wrapper.\n\nWarning for potentially destructive commands\n\nFor every command that is entered, the wrapper will assess the subcommand and\nits options. In that, it will first check if the subcommand (eg. add,\ncommit, rebase) is present in a list of predefined 'potentially destructive'\ncommands. This can be done by searching through a radix tree for the subcommand.\nIf found, then the arguments to the subcommand will be checked for specific\nflags. The graylisted flags for the destructive commands will be stored as an\narray of regular expressions, and the current command's arguments will be\nchecked against them. If matches are found, a warning is displayed. 'ggit'\nfor the warning would be\n\"You are about to do X, which will permanently destroy Y. Are you sure you wish\nto continue? [Y/n] \"\nIf the user enters Y[es], the command will be executed as is (by passing it\nunaltered to git). In the case of Y[es], 'ggit' will also give tips for undoing\nthe changes made by this command (by referring the user to correct commands and\nreflog), if the command can be undone. In case the command cannot be undone,\n'ggit' will display an additional line in the warning like\n\"The changes made by this command cannot be undone. Please proceed cautiously\".\nIn the case of n[o], 'ggit' will exit without executing the command.\n\nCurrently, the list consists of commands like:\n\n$ git rebase\n$ git reset --hard\n$ git clean -f\n$ git gc --prune=now --aggressive\n$ git push -f \n$ git push remote [+/:]\n$ git branch -D\n\nThe list will be updated after some more discussion on the list.\n\nUsage tips and documentation\n\nThe wrapper will also be responsible for showing a short description of every\ncommand that is entered through 'ggit'. This shall be done for every command\nunconditionally. The description will be derived from the actual documentation,\nbut will primarily aim to help the beginner understand the Git workflow and the\nGit model.\n\nA few examples to illustrate the working of the wrapper are:\n\n$ ggit add --all\nStaging all changes and untracked files. Use ` [g]git commit` to commit the\nchanges.\n\n$ ggit commit -m “Second commit”\nCommitting staged changes…\n[master 0be3142] Second commit\n 4 files changed, 6 insertions(+), 2 deletions(-)\n\n$ ggit reset HEAD~1 --hard\nResetting HEAD to 1 previous commit.\n[WARNING] You are about to hard reset the current HEAD (master) by 1 commit.\nThis will take you back to commit b16aae3, and discard all changes make\nthereafter. If you want to reset but also want to retain the changes made since,\nuse --soft instead of --hard.\nAre you sure you want to continue? [Y/n] y\nResetting HEAD to b16aae3…\nYou can undo this action by resetting the HEAD to last commit you were on, that\nis:\n`$ ggit reset HEAD 0be3142`\nIn general, you can see the previous positions of HEAD by running `git reflog`.\nHEAD is now at b16aae3 First commit\n\n$ ggit push --force origin master\nPushing changes to origin/master\n[WARNING] You are about to purge commits from the http://example.com/repo master\nbranch and overwrite its history to match yours.\n\nState right now:\n o---o---o---A---B master on http://example.com/repo\n \\\n X---Y---Z your master\n\nState if you continue:\n o---o---o---X---Y---Z master on http://example.com/repo and your master\n\nCommit A and B will be gone. If other people have worked on top of A or B then\nthey won't be able to merge their changes easily.\n\nAre you sure you want to continue? [Y/n] n\nAborting push to origin/master\n\nTimeline\n\nCommunity Bonding Period\n\nWeek 1 : Discuss the flow of course with the mentor. Discuss adequate data\nstructures and search techniques to be used.\n\nWeek 2-3 : Discuss over an extensive list of commands that should be classified\nas destructive. Discuss appropriate short descriptions for commands. Submit\nsample patches for the same for comments and review.\n\nWeek 4 : Discuss code structure, tests, optimization for least overhead and\nother details.\n\nCoding Starts\n\nWeek 1-2 : Submit code for a basic wrapper that will warn for a subset of the\npotentially destructive command, and continue if the command is safe.\nand this is stored as per to provide backward compatibility.\n\nWeek 3-5 : Extend the wrapper to warn for more commands in the list, along with\nproper instructions for undoing them. Write tests for the commands supported so\nfar.\n\nMid Term Evaluation\n\nWeek 6-7 : Complete support for all graylisted commands with tests.\n\nWeek 8-12: Add beginner-friendly documentation snippets to various git commands.\n\nWeek 13 : Final cleanup, final touches suggested by mentors and community.\n\nPens Down Date\nSubmission of Code to GSOC\n\n[1]: https://addons.mozilla.org/en-US/firefox/addon/owl/\n[2]: https://addons.mozilla.org/en-US/firefox/addon/blink/\n[3]: https://addons.mozilla.org/en-US/firefox/addon/spoiler-jedi/\n[4]: https://chrome.google.com/webstore/detail/blink-new-tab/kakaolkgegapcgdjdmlmcigejblohpkh/\n[5]: https://github.com/TigerKid001/flubbr\n[6]: http://eudyptula-challenge.org/\n[7]: https://github.com/TigerKid001/Perry\n[8]: https://github.com/TigerKid001/Dex\n[9]: https://addons.mozilla.org/en-US/firefox/\n[10]: http://git.github.io/SoC-2016-Ideas/#git-beginner\n"}]}