{"thread":{"id":"41676","subject":"[RFC/GSoC] Introduction","startedAt":"2016-03-12T06:59:10Z","lastAt":"2016-03-20T20:28:58Z","messageCount":23,"participants":["Sidhant Sharma","Lars Schneider","Kevin Daudt","Jacob Keller","Junio C Hamano","Philip Oakley","Matthieu Moy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"280658","messageId":"56E3BE3E.9070105@gmail.com","threadId":"41676","inReplyTo":null,"subject":"[RFC/GSoC] Introduction","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-03-12T06:59:10Z","receivedAt":"2016-03-12T06:59:10Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"Hi everyone!\n\nI am Sidhant Sharma, from Delhi, India. I'm a third year Software Engineering\nstudent at Delhi Technological University. I am looking to contribute to\nGit via GSoC 2016. I have also worked on one of the microprojects [1]. I've\nbeen using git for nearly two years now, and continue to be surprised by the\nvast number of features this powerful DVCS possesses. I want to contribute to\nGit because it has become a daily-use tool for me and it feels exciting to\nbe a part of the community that makes effective collaborative development\npossible.\n\nI would like to work on the project titled 'Git Beginner mode', and have been\nreading up the discussions that took place regarding this [2]. The reason I wish\nto take this project in particular is that when I initially started out with\nGit, and was still discovering how things really worked, I sometimes felt the\nneed for some sort of safety-latch to keep me from making destructive and/or\nirreversible changes. So, this project gives me the opportunity to implement\nsomething on these lines for the future beginners. I believe a lot of discussion\non the idea is due. I'm reading up on the commands that were mentioned on the\nproject page to better understand what the project entails, and trying to design\na solution for this, without making git harder to use or getting in the user's\nlearning. I would really appreciate your comments, suggestions and critique on\nthis.\n\nThanks and regards,\nSidhant Sharma\n\n[1]: http://thread.gmane.org/gmane.comp.version-control.git/288035\n[2]: http://thread.gmane.org/gmane.comp.version-control.git/285893/focus=286613\n"},{"id":"280685","messageId":"1924FEBB-46F2-46EE-B190-5289588D4BED@gmail.com","threadId":"41676","inReplyTo":"56E3BE3E.9070105@gmail.com","subject":"Re: [RFC/GSoC] Introduction","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-03-13T15:50:54Z","receivedAt":"2016-03-13T15:50:54Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"Hi Sidhant,\n\nthanks for your interest in the 'Git Beginner' mode topic. I completely \nunderstand your motivation for the topic as your Git learning experience\nmatches mine. However, please be aware that this is no easy project. The\nfinal implementation might be easy but it will require hard work to come \nup with a design for the beginner mode that the list considers to accept.\nThat being said, I am eager to learn about your ideas on the topic :-)\n\nBased on my previous discussions with Junio [3] I think on of the most \nimportant aspects is to ensure that Git does not become harder to use.\nI thought a while about this requirement and I wonder if a wrapper called \n'ggit' (guarded Git) could be a solution. The wrapper would pass all \ncommand line arguments to 'git' and check for potentially destructive \ncommands. If such a command is detected then the user would see a warning. \nIf the command is not destructive then 'ggit' would print a short instruction \nhow to \"undo\" it. The ordinary Git user would not be affected at all by the \nwrapper. A novice Git user who is unsure about his/her command line\nusage could use `ggit` as a safety net.\n\nI am curious about your opinions on this kind of approach. I wonder if\npeople would actually use such a wrapper.\n\nThanks,\nLars\n\n[3] http://thread.gmane.org/gmane.comp.version-control.git/285893/focus=286749\n\n\n\nOn 12 Mar 2016, at 07:59, Sidhant Sharma wrote:\n\n> Hi everyone!\n> \n> I am Sidhant Sharma, from Delhi, India. I'm a third year Software Engineering\n> student at Delhi Technological University. I am looking to contribute to\n> Git via GSoC 2016. I have also worked on one of the microprojects [1]. I've\n> been using git for nearly two years now, and continue to be surprised by the\n> vast number of features this powerful DVCS possesses. I want to contribute to\n> Git because it has become a daily-use tool for me and it feels exciting to\n> be a part of the community that makes effective collaborative development\n> possible.\n> \n> I would like to work on the project titled 'Git Beginner mode', and have been\n> reading up the discussions that took place regarding this [2]. The reason I wish\n> to take this project in particular is that when I initially started out with\n> Git, and was still discovering how things really worked, I sometimes felt the\n> need for some sort of safety-latch to keep me from making destructive and/or\n> irreversible changes. So, this project gives me the opportunity to implement\n> something on these lines for the future beginners. I believe a lot of discussion\n> on the idea is due. I'm reading up on the commands that were mentioned on the\n> project page to better understand what the project entails, and trying to design\n> a solution for this, without making git harder to use or getting in the user's\n> learning. I would really appreciate your comments, suggestions and critique on\n> this.\n> \n> Thanks and regards,\n> Sidhant Sharma\n> \n> [1]: http://thread.gmane.org/gmane.comp.version-control.git/288035\n> [2]: http://thread.gmane.org/gmane.comp.version-control.git/285893/focus=286613\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"280688","messageId":"56E5B27D.7010808@gmail.com","threadId":"41676","inReplyTo":"1924FEBB-46F2-46EE-B190-5289588D4BED@gmail.com","subject":"Re: [RFC/GSoC] Introduction","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-03-13T18:33:33Z","receivedAt":"2016-03-13T18:33:33Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"\n\nOn Sunday 13 March 2016 09:20 PM, Lars Schneider wrote:\n> Hi Sidhant,\n>\n> thanks for your interest in the 'Git Beginner' mode topic. I completely \n> understand your motivation for the topic as your Git learning experience\n> matches mine. However, please be aware that this is no easy project. The\n> final implementation might be easy but it will require hard work to come \n> up with a design for the beginner mode that the list considers to accept.\n> That being said, I am eager to learn about your ideas on the topic :-)\nHi,\n\nI understand that this project will require much effort to find an acceptable\nsolution and I'm prepared for it. I'm very excited to take this one up :)\n\n> Based on my previous discussions with Junio [3] I think on of the most \n> important aspects is to ensure that Git does not become harder to use.\n> I thought a while about this requirement and I wonder if a wrapper called \n> 'ggit' (guarded Git) could be a solution. The wrapper would pass all \n> command line arguments to 'git' and check for potentially destructive \n> commands. If such a command is detected then the user would see a warning. \n> If the command is not destructive then 'ggit' would print a short instruction \n> how to \"undo\" it. The ordinary Git user would not be affected at all by the \n> wrapper. A novice Git user who is unsure about his/her command line\n> usage could use `ggit` as a safety net.\n>\n> I am curious about your opinions on this kind of approach. I wonder if\n> people would actually use such a wrapper.\nCoincidentally, my approach too is a wrapper around git as you suggest.\nThe approach is simple and straight forward, but I wasn't sure if it would be\naccepted on the list, mainly because it may not look consistent with the current\ninterface `git command [options]`. Perhaps a configuration like\n`core.beginnerMode` [4] might be apt? By default, it can be false, making git\nbehave normally. When set, a safety-check can be run before the command is\nexecuted to ensure it's not potentially destructive. Very much like a wrapper\nbut on the inside. There can be an option like `--no-beginner` to override\nthis configuration from the command-line. I was wondering if there should be\ncommand-specific options as well, such as `beginner.allowForcePush`,\n`beginner.allowRebase` etc. for a finer control over what commands git would warn\nthe user about. By default, all are set to false, and warning is shown when any\nof them is encountered. Another configuration that may be considered is\n`beginner.strict`, which when set would just print the warning and die, instead\nof giving the user an option to continue (though I'm a little unsure whether\nthis one would be a good idea).\nOne thing that bothers me about this approach is that unlike the explicit 'ggit'\nwrapper, an internal wrapper would add (unnecessary?) overhead for most commands,\nthus impacting the performance. Will that be an issue?\n\nAlong with this, the idea of showing a short instruction for undoing commands\nsounds very nice as it'll help beginners to understand and use git better.\n\nI'm eager to know your opinions on this approach :)\n\nOther than this, I also tried to expand the list of potentially destructive\ncommands and updated the list as follows (additions in brackets):\n\n* git rebase [ git pull --rebase ]\n* git reset --hard\n* git clean -f\n* git gc --prune=now --aggressive\n* git push -f [ git push :, git push + ]\n* [ git branch -D ]\n\nAre these additions appropriate? What other commands should be included?\n\n\nThanks and regards,\nSidhant Sharma\n\n\n[4]: http://thread.gmane.org/gmane.comp.version-control.git/285893/focus=286663\n"},{"id":"280690","messageId":"20160313211910.GA22052@ikke.info","threadId":"41676","inReplyTo":"56E5B27D.7010808@gmail.com","subject":"Re: [RFC/GSoC] Introduction","fromName":"Kevin Daudt","fromEmail":"me@ikke.info","sentAt":"2016-03-13T21:19:10Z","receivedAt":"2016-03-13T21:19:10Z","isPatch":false,"sender":{"key":"me@ikke.info","avatar":"https://avatars.githubusercontent.com/u/135698?v=4"},"body":"On Mon, Mar 14, 2016 at 12:03:33AM +0530, Sidhant Sharma wrote:\n> \n> \n> \n> Other than this, I also tried to expand the list of potentially destructive\n> commands and updated the list as follows (additions in brackets):\n> \n> * git rebase [ git pull --rebase ]\n> * git reset --hard\n> * git clean -f\n> * git gc --prune=now --aggressive\n> * git push -f [ git push :, git push + ]\n> * [ git branch -D ]\n> \n> Are these additions appropriate? What other commands should be included?\n> \n> \n\ngit checkout [ref] is destructive too if it would overwrite an\nuncomitted change.\n"},{"id":"280691","messageId":"CA+P7+xp3drFd9rSkxSH9P4PfxFrXvDU9kFib1dtBFdVC5R+ZRg@mail.gmail.com","threadId":"41676","inReplyTo":"56E5B27D.7010808@gmail.com","subject":"Re: [RFC/GSoC] Introduction","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-03-13T23:28:55Z","receivedAt":"2016-03-13T23:28:55Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Sun, Mar 13, 2016 at 11:33 AM, Sidhant Sharma wrote:\n> Coincidentally, my approach too is a wrapper around git as you suggest.\n> The approach is simple and straight forward, but I wasn't sure if it would be\n> accepted on the list, mainly because it may not look consistent with the current\n> interface `git command [options]`. Perhaps a configuration like\n> `core.beginnerMode` [4] might be apt? By default, it can be false, making git\n> behave normally. When set, a safety-check can be run before the command is\n> executed to ensure it's not potentially destructive. Very much like a wrapper\n> but on the inside. There can be an option like `--no-beginner` to override\n> this configuration from the command-line. I was wondering if there should be\n> command-specific options as well, such as `beginner.allowForcePush`,\n> `beginner.allowRebase` etc. for a finer control over what commands git would warn\n> the user about. By default, all are set to false, and warning is shown when any\n> of them is encountered. Another configuration that may be considered is\n> `beginner.strict`, which when set would just print the warning and die, instead\n> of giving the user an option to continue (though I'm a little unsure whether\n> this one would be a good idea).\n> One thing that bothers me about this approach is that unlike the explicit 'ggit'\n> wrapper, an internal wrapper would add (unnecessary?) overhead for most commands,\n> thus impacting the performance. Will that be an issue?\n>\n\nIf I recall correctly, a configuration setting was previously\ndiscussed but mostly discarded as a solution since any changes had\nbetter not impact any current scripts. Having to add \"--no-beginner\"\nfor all of them seems unacceptable. Especially since many scripts may\ndo potentially dangerous operations in a safe or useful way.\n\nThanks,\nJake\n"},{"id":"280696","messageId":"56E64B47.5000000@gmail.com","threadId":"41676","inReplyTo":"CA+P7+xp3drFd9rSkxSH9P4PfxFrXvDU9kFib1dtBFdVC5R+ZRg@mail.gmail.com","subject":"Re: [RFC/GSoC] Introduction","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-03-14T05:25:27Z","receivedAt":"2016-03-14T05:25:27Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"\nOn Monday 14 March 2016 04:58 AM, Jacob Keller wrote:\n> On Sun, Mar 13, 2016 at 11:33 AM, Sidhant Sharma wrote:\n>> Coincidentally, my approach too is a wrapper around git as you suggest.\n>> The approach is simple and straight forward, but I wasn't sure if it would be\n>> accepted on the list, mainly because it may not look consistent with the current\n>> interface `git command [options]`. Perhaps a configuration like\n>> `core.beginnerMode` [4] might be apt? By default, it can be false, making git\n>> behave normally. When set, a safety-check can be run before the command is\n>> executed to ensure it's not potentially destructive. Very much like a wrapper\n>> but on the inside. There can be an option like `--no-beginner` to override\n>> this configuration from the command-line. I was wondering if there should be\n>> command-specific options as well, such as `beginner.allowForcePush`,\n>> `beginner.allowRebase` etc. for a finer control over what commands git would warn\n>> the user about. By default, all are set to false, and warning is shown when any\n>> of them is encountered. Another configuration that may be considered is\n>> `beginner.strict`, which when set would just print the warning and die, instead\n>> of giving the user an option to continue (though I'm a little unsure whether\n>> this one would be a good idea).\n>> One thing that bothers me about this approach is that unlike the explicit 'ggit'\n>> wrapper, an internal wrapper would add (unnecessary?) overhead for most commands,\n>> thus impacting the performance. Will that be an issue?\n>>\n> If I recall correctly, a configuration setting was previously\n> discussed but mostly discarded as a solution since any changes had\n> better not impact any current scripts. Having to add \"--no-beginner\"\n> for all of them seems unacceptable. Especially since many scripts may\n> do potentially dangerous operations in a safe or useful way.\n>\nI agree that adding `--no-beginner` to all such commands wouldn't be right. In\nthat case, can we have the flag between git and the command? Such as\n`git --no-beginner reset --hard`. If present, the flag can then be removed from\nthe argument list and the rest of the command executed as is without warning.\nWould that a better option?\n\n\nThanks and regards,\nSidhant Sharma\n"},{"id":"280697","messageId":"56E64B5C.7030405@gmail.com","threadId":"41676","inReplyTo":"20160313211910.GA22052@ikke.info","subject":"Re: [RFC/GSoC] Introduction","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-03-14T05:25:49Z","receivedAt":"2016-03-14T05:25:49Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"\nOn Monday 14 March 2016 02:49 AM, Kevin Daudt wrote:\n> On Mon, Mar 14, 2016 at 12:03:33AM +0530, Sidhant Sharma wrote:\n>> Other than this, I also tried to expand the list of potentially destructive\n>> commands and updated the list as follows (additions in brackets):\n>>\n>> * git rebase [ git pull --rebase ]\n>> * git reset --hard\n>> * git clean -f\n>> * git gc --prune=now --aggressive\n>> * git push -f [ git push :, git push + ]\n>> * [ git branch -D ]\n>>\n>> Are these additions appropriate? What other commands should be included?\n>>\n> git checkout [ref] is destructive too if it would overwrite an\n> uncomitted change.\nThanks, I'll add that one too. Also, should git checkout -- be\nadded, since it'll discard all uncommitted changes?\n\nRegards,\nSidhant Sharma\n"},{"id":"280698","messageId":"CA+P7+xqsjY--_0aQgJKKNOBONDL5ULkRw+z+J7ATyJC=KWC1qg@mail.gmail.com","threadId":"41676","inReplyTo":"56E64B47.5000000@gmail.com","subject":"Re: [RFC/GSoC] Introduction","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-03-14T06:14:02Z","receivedAt":"2016-03-14T06:14:02Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Sun, Mar 13, 2016 at 10:25 PM, Sidhant Sharma wrote:\n>\n> On Monday 14 March 2016 04:58 AM, Jacob Keller wrote:\n>> On Sun, Mar 13, 2016 at 11:33 AM, Sidhant Sharma wrote:\n>>> Coincidentally, my approach too is a wrapper around git as you suggest.\n>>> The approach is simple and straight forward, but I wasn't sure if it would be\n>>> accepted on the list, mainly because it may not look consistent with the current\n>>> interface `git command [options]`. Perhaps a configuration like\n>>> `core.beginnerMode` [4] might be apt? By default, it can be false, making git\n>>> behave normally. When set, a safety-check can be run before the command is\n>>> executed to ensure it's not potentially destructive. Very much like a wrapper\n>>> but on the inside. There can be an option like `--no-beginner` to override\n>>> this configuration from the command-line. I was wondering if there should be\n>>> command-specific options as well, such as `beginner.allowForcePush`,\n>>> `beginner.allowRebase` etc. for a finer control over what commands git would warn\n>>> the user about. By default, all are set to false, and warning is shown when any\n>>> of them is encountered. Another configuration that may be considered is\n>>> `beginner.strict`, which when set would just print the warning and die, instead\n>>> of giving the user an option to continue (though I'm a little unsure whether\n>>> this one would be a good idea).\n>>> One thing that bothers me about this approach is that unlike the explicit 'ggit'\n>>> wrapper, an internal wrapper would add (unnecessary?) overhead for most commands,\n>>> thus impacting the performance. Will that be an issue?\n>>>\n>> If I recall correctly, a configuration setting was previously\n>> discussed but mostly discarded as a solution since any changes had\n>> better not impact any current scripts. Having to add \"--no-beginner\"\n>> for all of them seems unacceptable. Especially since many scripts may\n>> do potentially dangerous operations in a safe or useful way.\n>>\n> I agree that adding `--no-beginner` to all such commands wouldn't be right. In\n> that case, can we have the flag between git and the command? Such as\n> `git --no-beginner reset --hard`. If present, the flag can then be removed from\n> the argument list and the rest of the command executed as is without warning.\n> Would that a better option?\n>\n>\n> Thanks and regards,\n> Sidhant Sharma\n>\n\nNo, the whole problem with \"--no-beginner\" is that scripts must either\ncheck the configuration variable or add the flag. Since, by definition\nexactly zero scripts do that today, then every script must either (a)\nbe re-written, (b) accept that some behavior will not work as\nexpected.\n\nMost (robust) scripts will already check for aliases, and if not, the\nuser should expect that doing weird things to their environment in\nthis way would cause things to break.\n\nI don't think we can create a design where scripts must be re-written\nto protect themselves or accept misbehaving in those ways.\n\nIf we had a clear (used) delineation between porcelain and plumbing\ncommands, we could have all the porcelain commands accept an argument\nbut not plumbing. Except that (a) all plumbing commands can be called\nfrom the path relatively easily so a user might still want protection\non those too and (b) we don't actually have an enforced\nplumbing/porcelain distinction. While we document one, several scripts\nexist in the wild which violate this and which we may want to support.\n\nI think that we could go this route, but we'd have to be willing to\naccept (a) or (b), above as costs to this route. Personally I prefer\nthe wrapper approach since it neatly bypasses all of this behavior and\nseems easier to implement. It's major downside is telling beginners\nto use \"ggit\" or similar, which is a big deal.\n\nWe have broken scripts in the past or changed behavior of commands\nbefore. But it is done using a phased transition with lots of\nwarnings. It is possible that the gain is large enough to be worth it.\nIn this case, I think we should heavily way that side because helping\npeople learn git is a huge win. I can't count how many times I've had\nto tell someone \"you really didn't mean to do that\" and wished for a\nway to help avoid this.\n\nBut, it is a cost to adding an option that any scripting, push/pull\nhooks or other complex workflows would have to be thought through\ncarefully.\n\nThanks,\nJake\n"},{"id":"280699","messageId":"CA+P7+xpCJKYLq_vzOm=sD=oNOV0fsVphRkem3JF4iMf1EWV1HQ@mail.gmail.com","threadId":"41676","inReplyTo":"56E64B5C.7030405@gmail.com","subject":"Re: [RFC/GSoC] Introduction","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-03-14T06:15:58Z","receivedAt":"2016-03-14T06:15:58Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Sun, Mar 13, 2016 at 10:25 PM, Sidhant Sharma wrote:\n>\n> On Monday 14 March 2016 02:49 AM, Kevin Daudt wrote:\n>> On Mon, Mar 14, 2016 at 12:03:33AM +0530, Sidhant Sharma wrote:\n>>> Other than this, I also tried to expand the list of potentially destructive\n>>> commands and updated the list as follows (additions in brackets):\n>>>\n>>> * git rebase [ git pull --rebase ]\n\nFor rebase, it is tricky since many work flows and setups use it a lot\nin ways that aren't a problem. Ideally we'd be able to warn about\ncases where it is very bad, but not in cases where it isn't likely to\ncause problems. It may be that it isn't possible to programatically\ndetermine this though.\n\nRegards,\nJake\n"},{"id":"280700","messageId":"xmqqk2l58s2a.fsf@gitster.mtv.corp.google.com","threadId":"41676","inReplyTo":"1924FEBB-46F2-46EE-B190-5289588D4BED@gmail.com","subject":"Re: [RFC/GSoC] Introduction","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-14T06:57:49Z","receivedAt":"2016-03-14T06:57:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Lars Schneider writes:\n\n> I thought a while about this requirement and I wonder if a wrapper called \n> 'ggit' (guarded Git) could be a solution. The wrapper would pass all \n> command line arguments to 'git' and check for potentially destructive \n> commands. If such a command is detected then the user would see a warning.\n\nI recall back in the days when people said that Hg's command set was\nso much more pleasant to use that some people thought about building\nHg's command line UI on top of low level implementation of the Git's\ndata structure. Even before that time, there was an effort \"Cogito\"\nto build an alternate UI on top of Git core. If \"ggit\" can be made\nreasonably feature complete in such a way that it lets beginners do\nall what they need to do, omitting many advanced/hairy features core\nGit may let users use (i.e. making trade-off between power and risk\nof misuse differently from core Git), that may be a reasonable way\nto offer a \"beginner mode\".\n\nThe beauty of such an approach is that as long as \"ggit\" correctly\ntalks the same on-wire protocol when interacting with other people's\nrepositories, nobody needs to even know or care that you are using\n\"ggit\" exclusively. Two systems can talk without problems.\n\nIf \"ggit\" is made too limited, there is an issue. Beginners may at\nsome point need to transition to the real thing to fully exploit the\npower of Git, and they may need to unlearn \"ggit\" and learn Git.\nThis approach, if it wants to become successful in helping users,\nwould take quite a lot of thinking and work to avoid omitting too\nmuch to necessitate users to migrate to Git. But I can very well\nimagine that a new \"Cogito 2\" project (I am not saying that the UI\nCogito tried to achieve were superiour or anything of that sort--I\njust needed a name, and picked one name that came to my mind) may\nget done by those who interact rarely with the core Git community\nand may live as one of many independent and viable third-party\nprojects you find on GitHub.\n\nThere however are two questions I do not offhand have good answers\nto: (1) if that kind of effort is of suitable size for GSoC, and (2)\nif it is suitable to be supported by the Git project proper.\n"},{"id":"280701","messageId":"xmqqfuvt8rws.fsf@gitster.mtv.corp.google.com","threadId":"41676","inReplyTo":"20160313211910.GA22052@ikke.info","subject":"Re: [RFC/GSoC] Introduction","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-14T07:01:07Z","receivedAt":"2016-03-14T07:01:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kevin Daudt writes:\n\n> On Mon, Mar 14, 2016 at 12:03:33AM +0530, Sidhant Sharma wrote:\n>> \n>> \n>> \n>> Other than this, I also tried to expand the list of potentially destructive\n>> commands and updated the list as follows (additions in brackets):\n>> \n>> * git rebase [ git pull --rebase ]\n>> * git reset --hard\n>> * git clean -f\n>> * git gc --prune=now --aggressive\n>> * git push -f [ git push :, git push + ]\n>> * [ git branch -D ]\n>> \n>> Are these additions appropriate? What other commands should be included?\n>\n> git checkout [ref] is destructive too if it would overwrite an\n> uncomitted change.\n\nObviously. As that was designed to be the way to get rid of\nunsuccessful/unwanted edit in the working tree.\n\n\"git add \" is destructive if it overwrites the index entry\nthat holds contents you have not committed.\n\n\"git rm [--cached] \" is destructive, too.\n\nI think \"git checkout [] \" falls into the same category.\n"},{"id":"280703","messageId":"FB2E0900-A77E-4AE2-A580-9192746A8ABA@gmail.com","threadId":"41676","inReplyTo":"xmqqk2l58s2a.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC/GSoC] Introduction","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-03-14T08:16:01Z","receivedAt":"2016-03-14T08:16:01Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\nOn 14 Mar 2016, at 07:57, Junio C Hamano wrote:\n\n> Lars Schneider writes:\n> \n>> I thought a while about this requirement and I wonder if a wrapper called \n>> 'ggit' (guarded Git) could be a solution. The wrapper would pass all \n>> command line arguments to 'git' and check for potentially destructive \n>> commands. If such a command is detected then the user would see a warning.\n> \n> I recall back in the days when people said that Hg's command set was\n> so much more pleasant to use that some people thought about building\n> Hg's command line UI on top of low level implementation of the Git's\n> data structure. Even before that time, there was an effort \"Cogito\"\n> to build an alternate UI on top of Git core. If \"ggit\" can be made\n> reasonably feature complete in such a way that it lets beginners do\n> all what they need to do, omitting many advanced/hairy features core\n> Git may let users use (i.e. making trade-off between power and risk\n> of misuse differently from core Git), that may be a reasonable way\n> to offer a \"beginner mode\".\n> \n> The beauty of such an approach is that as long as \"ggit\" correctly\n> talks the same on-wire protocol when interacting with other people's\n> repositories, nobody needs to even know or care that you are using\n> \"ggit\" exclusively. Two systems can talk without problems.\n> \n> If \"ggit\" is made too limited, there is an issue. Beginners may at\n> some point need to transition to the real thing to fully exploit the\n> power of Git, and they may need to unlearn \"ggit\" and learn Git.\n\nI think a \"ggit\" wrapper should not introduce any new commands or new\nparameters. Everything should be passed unmodified to Git. The wrapper\nwould only add additional warnings such as \"You are about to do X which \nwill permanently destroy Y. Do you want to continue?\". Therefore\na transition from \"ggit\" to \"git\" would not require any learning effort.\n\nMaybe \"ggit\" could also be interpreted as \"guided Git\" (sounds more \nfriendly than \"guarded Git\"). I have the impression that many Git \nbeginners make mistakes because they don't have a mental model of Git,\nyet. A \"guided\" Git version could explain the commands a bit more \ndetailed as they use Git (e.g. with ASCII graph examples). I know\nthat's what man pages are for but I've encountered many users \n(especially on Windows) that are not aware of man pages.\n\n\n> This approach, if it wants to become successful in helping users,\n> would take quite a lot of thinking and work to avoid omitting too\n> much to necessitate users to migrate to Git. But I can very well\n> imagine that a new \"Cogito 2\" project (I am not saying that the UI\n> Cogito tried to achieve were superiour or anything of that sort--I\n> just needed a name, and picked one name that came to my mind) may\n> get done by those who interact rarely with the core Git community\n> and may live as one of many independent and viable third-party\n> projects you find on GitHub.\n> \n> There however are two questions I do not offhand have good answers\n> to: (1) if that kind of effort is of suitable size for GSoC, and (2)\n> if it is suitable to be supported by the Git project proper.\n\nGood questions. I have no previous experience with GSoC Git projects\nand therefore I am not qualified for an answer. However, my gut feeling\nwould be that a proof of concept implementation of a \"ggit\" wrapper\nthat does not add any new commands and only adds warnings for destructive\ncommands could be in the GSoC scope. However, Sidhant must be aware of\nthe fact that this is a controversial topic and therefore any future work\non this topic might be never merged into Git.\n\nI also thought about (2). The obvious advantage of having something like \n\"ggit\" as part of Git core is that it would be shipped with the standard\nGit distribution. That would especially help beginners. However, \nmaintenance is a very strong counter argument. Maybe \"ggit\" could\nstart as a separate project and if it picks up then Git core can still\ndecide to merge it?\n"},{"id":"280714","messageId":"56E6DF17.2040106@gmail.com","threadId":"41676","inReplyTo":"FB2E0900-A77E-4AE2-A580-9192746A8ABA@gmail.com","subject":"Re: [RFC/GSoC] Introduction","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-03-14T15:56:07Z","receivedAt":"2016-03-14T15:56:07Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"On Monday 14 March 2016 01:46 PM, Lars Schneider wrote:\n> On 14 Mar 2016, at 07:57, Junio C Hamano wrote:\n>\n>> If \"ggit\" is made too limited, there is an issue. Beginners may at\n>> some point need to transition to the real thing to fully exploit the\n>> power of Git, and they may need to unlearn \"ggit\" and learn Git.\n> I think a \"ggit\" wrapper should not introduce any new commands or new\n> parameters. Everything should be passed unmodified to Git. The wrapper\n> would only add additional warnings such as \"You are about to do X which \n> will permanently destroy Y. Do you want to continue?\". Therefore\n> a transition from \"ggit\" to \"git\" would not require any learning effort.\n>\n> Maybe \"ggit\" could also be interpreted as \"guided Git\" (sounds more \n> friendly than \"guarded Git\"). I have the impression that many Git \n> beginners make mistakes because they don't have a mental model of Git,\n> yet. A \"guided\" Git version could explain the commands a bit more \n> detailed as they use Git (e.g. with ASCII graph examples). I know\n> that's what man pages are for but I've encountered many users \n> (especially on Windows) that are not aware of man pages.\nI too think that the wrapper should only pass on commands to git if\nthey aren't potentially destructive, and not itself introduce\nnew commands, unless there is a need (I doubt if there will be).\n>\n>> This approach, if it wants to become successful in helping users,\n>> would take quite a lot of thinking and work to avoid omitting too\n>> much to necessitate users to migrate to Git. But I can very well\n>> imagine that a new \"Cogito 2\" project (I am not saying that the UI\n>> Cogito tried to achieve were superiour or anything of that sort--I\n>> just needed a name, and picked one name that came to my mind) may\n>> get done by those who interact rarely with the core Git community\n>> and may live as one of many independent and viable third-party\n>> projects you find on GitHub.\n>>\n>> There however are two questions I do not offhand have good answers\n>> to: (1) if that kind of effort is of suitable size for GSoC, and (2)\n>> if it is suitable to be supported by the Git project proper.\n> Good questions. I have no previous experience with GSoC Git projects\n> and therefore I am not qualified for an answer. However, my gut feeling\n> would be that a proof of concept implementation of a \"ggit\" wrapper\n> that does not add any new commands and only adds warnings for destructive\n> commands could be in the GSoC scope. However, Sidhant must be aware of\n> the fact that this is a controversial topic and therefore any future work\n> on this topic might be never merged into Git.\n>\n> I also thought about (2). The obvious advantage of having something like \n> \"ggit\" as part of Git core is that it would be shipped with the standard\n> Git distribution. That would especially help beginners. However, \n> maintenance is a very strong counter argument. Maybe \"ggit\" could\n> start as a separate project and if it picks up then Git core can still\n> decide to merge it?\n>\nI understand that this endeavour may or may not be merged into\nthe official Git distribution (though I'd really like it to :)), but\nI still wish to attempt this. I'm also eager to continue work on this\neven after GSoC is over, so maintenance shouldn't be an issue ;)\n\nThanks and regards,\nSidhant Sharma\n"},{"id":"280717","messageId":"56E6E017.1080709@gmail.com","threadId":"41676","inReplyTo":"CA+P7+xqsjY--_0aQgJKKNOBONDL5ULkRw+z+J7ATyJC=KWC1qg@mail.gmail.com","subject":"Re: [RFC/GSoC] Introduction","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-03-14T16:00:23Z","receivedAt":"2016-03-14T16:00:23Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"\nOn Monday 14 March 2016 11:44 AM, Jacob Keller wrote:\n> On Sun, Mar 13, 2016 at 10:25 PM, Sidhant Sharma wrote:\n>> On Monday 14 March 2016 04:58 AM, Jacob Keller wrote:\n>>>\n>>> If I recall correctly, a configuration setting was previously\n>>> discussed but mostly discarded as a solution since any changes had\n>>> better not impact any current scripts. Having to add \"--no-beginner\"\n>>> for all of them seems unacceptable. Especially since many scripts may\n>>> do potentially dangerous operations in a safe or useful way.\n>>>\n>> I agree that adding `--no-beginner` to all such commands wouldn't be right. In\n>> that case, can we have the flag between git and the command? Such as\n>> `git --no-beginner reset --hard`. If present, the flag can then be removed from\n>> the argument list and the rest of the command executed as is without warning.\n>> Would that a better option?\n>>\n>>\n>> Thanks and regards,\n>> Sidhant Sharma\n>>\n> No, the whole problem with \"--no-beginner\" is that scripts must either\n> check the configuration variable or add the flag. Since, by definition\n> exactly zero scripts do that today, then every script must either (a)\n> be re-written, (b) accept that some behavior will not work as\n> expected.\n>\n> Most (robust) scripts will already check for aliases, and if not, the\n> user should expect that doing weird things to their environment in\n> this way would cause things to break.\n>\n> I don't think we can create a design where scripts must be re-written\n> to protect themselves or accept misbehaving in those ways.\n>\n> If we had a clear (used) delineation between porcelain and plumbing\n> commands, we could have all the porcelain commands accept an argument\n> but not plumbing. Except that (a) all plumbing commands can be called\n> from the path relatively easily so a user might still want protection\n> on those too and (b) we don't actually have an enforced\n> plumbing/porcelain distinction. While we document one, several scripts\n> exist in the wild which violate this and which we may want to support.\n>\n> I think that we could go this route, but we'd have to be willing to\n> accept (a) or (b), above as costs to this route. Personally I prefer\n> the wrapper approach since it neatly bypasses all of this behavior and\n> seems easier to implement. It's major downside is telling beginners\n> to use \"ggit\" or similar, which is a big deal.\nThanks for elaborating on that. I now understand why the configuration\noption approach is not fit. The 'ggit' wrapper does sound more\napt for this. I do realize telling the beginners to use 'ggit' instead \nof just 'git' is a shortcoming of this approach, but perhaps it's worth\nit if it makes Git easier to use and understand for beginners. Lars'\nsuggestion of short instructions would be really nice for helping\nbeginners form a mental picture of git workflow, and might be worth\nthe trade-off.\n\n\nThanks and regards,\nSidhant Sharma\n"},{"id":"280720","messageId":"xmqq7fh5as54.fsf@gitster.mtv.corp.google.com","threadId":"41676","inReplyTo":"FB2E0900-A77E-4AE2-A580-9192746A8ABA@gmail.com","subject":"Re: [RFC/GSoC] Introduction","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-14T17:25:27Z","receivedAt":"2016-03-14T17:25:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Lars Schneider writes:\n\n> On 14 Mar 2016, at 07:57, Junio C Hamano wrote:\n>\n>> I recall back in the days when people said that Hg's command set was\n>> so much more pleasant to use that some people thought about building\n>> Hg's command line UI on top of low level implementation of the Git's\n>> data structure....\n>> ...\n>\n> I think a \"ggit\" wrapper should not introduce any new commands or\n> new parameters. Everything should be passed unmodified to Git.\n> The wrapper would only add additional warnings...\n\nSomehow I was assuming that you are aiming for a more ambitious\nproject, where the users get an easier-to-learn-and-understand\ncommand line UI experience than bare Git [*1*], but none of what I\nsaid about \"limiting and omitting\" applies if \"ggit\" will be a\n\"passthru after examining what goes on\" wrapper.\n\n> Maybe \"ggit\" could also be interpreted as \"guided Git\" (sounds more \n> friendly than \"guarded Git\"). I have the impression that many Git \n> beginners make mistakes because they don't have a mental model of Git,\n> yet. A \"guided\" Git version could explain the commands a bit more \n> detailed as they use Git (e.g. with ASCII graph examples). I know\n> that's what man pages are for but I've encountered many users \n> (especially on Windows) that are not aware of man pages.\n\nounds like a lot of work but still a sensible goal. And that leaves\nno room for questioning if it is suitable for Git GSOC, at least to\nme--it does fall into the scope of making experience of learning\nbetter for Git itself.\n\nThanks.\n\n\n[Footnote]\n\n*1* For example, subversion migrants may say it is confusing to call\n the command \"checkout\" that is used to clobber files in the\n working tree to the state in the index and may want to call it\n \"revert\"--and \"$SCM revert $path\" would be the way the more\n ambitious project would let its users do that operation; it\n would call underlying \"git checkout $path\" for its users.\n There are other command line UI restructuring that will not\n belong to Git itself but an alternative UI front-end may want to\n use, e.g. \"$SCM diff INDEX WORKTREE $pathname\" that is turned\n into \"git diff $pathname\" and \"$SCM diff HEAD INDEX $pathname\"\n that is turned into \"git diff --cached HEAD $pathname\".\n"},{"id":"280741","messageId":"2F4E620D0B79497F837DC1D045B0467E@PhilipOakley","threadId":"41676","inReplyTo":"FB2E0900-A77E-4AE2-A580-9192746A8ABA@gmail.com","subject":"Re: [RFC/GSoC] Introduction","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2016-03-14T20:50:47Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Lars Schneider\" \n>\n> On 14 Mar 2016, at 07:57, Junio C Hamano wrote:\n>\n>> Lars Schneider writes:\n>>\n>>> I thought a while about this requirement and I wonder if a wrapper \n>>> called\n>>> 'ggit' (guarded Git) could be a solution. The wrapper would pass all\n>>> command line arguments to 'git' and check for potentially destructive\n>>> commands. If such a command is detected then the user would see a \n>>> warning.\n>>\n>> I recall back in the days when people said that Hg's command set was\n>> so much more pleasant to use that some people thought about building\n>> Hg's command line UI on top of low level implementation of the Git's\n>> data structure. Even before that time, there was an effort \"Cogito\"\n>> to build an alternate UI on top of Git core. If \"ggit\" can be made\n>> reasonably feature complete in such a way that it lets beginners do\n>> all what they need to do, omitting many advanced/hairy features core\n>> Git may let users use (i.e. making trade-off between power and risk\n>> of misuse differently from core Git), that may be a reasonable way\n>> to offer a \"beginner mode\".\n>>\n>> The beauty of such an approach is that as long as \"ggit\" correctly\n>> talks the same on-wire protocol when interacting with other people's\n>> repositories, nobody needs to even know or care that you are using\n>> \"ggit\" exclusively. Two systems can talk without problems.\n>>\n>> If \"ggit\" is made too limited, there is an issue. Beginners may at\n>> some point need to transition to the real thing to fully exploit the\n>> power of Git, and they may need to unlearn \"ggit\" and learn Git.\n>\n> I think a \"ggit\" wrapper should not introduce any new commands or new\n> parameters. Everything should be passed unmodified to Git. The wrapper\n> would only add additional warnings such as \"You are about to do X which\n> will permanently destroy Y. Do you want to continue?\". Therefore\n> a transition from \"ggit\" to \"git\" would not require any learning effort.\n>\n> Maybe \"ggit\" could also be interpreted as \"guided Git\" (sounds more\n> friendly than \"guarded Git\"). I have the impression that many Git\n> beginners make mistakes because they don't have a mental model of Git,\n> yet. A \"guided\" Git version could explain the commands a bit more\n> detailed as they use Git (e.g. with ASCII graph examples).\n\n+1 on \"guided\" as a softer more (beginner) friendly term.\n\n> I know\n> that's what man pages are for but I've encountered many users\n> (especially on Windows) that are not aware of man pages.\n\nIn previous discussion it has been said that that (teaching and explaining) \nis not the purpose of man pages. Rather, the man pages are for reference for \nthose who already have a reasonable idea of what they are doing, and use the \nman page to check on details.\n\nWhether the man pages should have more examples (or a makefile option to \ninclude them) may be part of the beginner mode mix, and may come out of (or \ngo into) the guidance examples.\n\nThe Git data model is very powerful and it does take a lot of 'unlearning' \nof old expectations (which is very hard) before the capabilities of the git \nmodel become well established in the users mind. For example, remote \ntracking branches are not remote but local, and are a reverse polish \ndescription (a local branch which keeps track of a remote's branch, from the \nlast time you looked).\n\nDifferent people get different parts of the model in different orders and \ndifferent rates. Identifying the many issues (in model understanding) may be \na start for identifying which command/options should be targeted.\n\n>\n>\n>> This approach, if it wants to become successful in helping users,\n>> would take quite a lot of thinking and work to avoid omitting too\n>> much to necessitate users to migrate to Git. But I can very well\n>> imagine that a new \"Cogito 2\" project (I am not saying that the UI\n>> Cogito tried to achieve were superiour or anything of that sort--I\n>> just needed a name, and picked one name that came to my mind) may\n>> get done by those who interact rarely with the core Git community\n>> and may live as one of many independent and viable third-party\n>> projects you find on GitHub.\n>>\n>> There however are two questions I do not offhand have good answers\n>> to: (1) if that kind of effort is of suitable size for GSoC, and (2)\n>> if it is suitable to be supported by the Git project proper.\n>\n> Good questions. I have no previous experience with GSoC Git projects\n> and therefore I am not qualified for an answer. However, my gut feeling\n> would be that a proof of concept implementation of a \"ggit\" wrapper\n> that does not add any new commands and only adds warnings for destructive\n> commands could be in the GSoC scope. However, Sidhant must be aware of\n> the fact that this is a controversial topic and therefore any future work\n> on this topic might be never merged into Git.\n>\n> I also thought about (2). The obvious advantage of having something like\n> \"ggit\" as part of Git core is that it would be shipped with the standard\n> Git distribution. That would especially help beginners. However,\n> maintenance is a very strong counter argument. Maybe \"ggit\" could\n> start as a separate project and if it picks up then Git core can still\n> decide to merge it?\n>\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n"},{"id":"281045","messageId":"56EAC49B.6020909@gmail.com","threadId":"41676","inReplyTo":"1924FEBB-46F2-46EE-B190-5289588D4BED@gmail.com","subject":"Re: [RFC/GSoC] Introduction","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-03-17T14:52:11Z","receivedAt":"2016-03-17T14:52:11Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"Hi,\n\nSo to sum up, the list of tasks for the project would be:\n1. A wrapper is to be implemented around (called 'ggit') that will scan the\narguments for potentially destructive commands. When none are found, all the\narguments will simply be passed through to git.\n2. If such a command is found, 'ggit' will:\n a. Show what the command is actually going to do.\n b. Ask the user if they are sure they want to execute it.\nEg. \"You are about to do X which will permanently destroy Y. Do you want to\ncontinue?\"\n3. For all commands that are entered, 'ggit' will also show a brief summary of\nthe command what it will do when executed, explaining it's intended usage.\n\nIs the list correct, or did I miss something?\n\n\nThanks and regards,\nSidhant Sharma\n"},{"id":"281283","messageId":"33EDD26C-ED5A-42EE-B523-240AEF5C51B7@gmail.com","threadId":"41676","inReplyTo":"56EAC49B.6020909@gmail.com","subject":"Re: [RFC/GSoC] Introduction","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-03-20T15:39:32Z","receivedAt":"2016-03-20T15:39:32Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"Hi Sidhant,\n\nthat sounds about right to me. In what language do you plan to implement the \nwrapper?\n\nBest,\nLars\n\nOn 17 Mar 2016, at 15:52, Sidhant Sharma wrote:\n\n> Hi,\n> \n> So to sum up, the list of tasks for the project would be:\n> 1. A wrapper is to be implemented around (called 'ggit') that will scan the\n> arguments for potentially destructive commands. When none are found, all the\n> arguments will simply be passed through to git.\n> 2. If such a command is found, 'ggit' will:\n> a. Show what the command is actually going to do.\n> b. Ask the user if they are sure they want to execute it.\n> Eg. \"You are about to do X which will permanently destroy Y. Do you want to\n> continue?\"\n> 3. For all commands that are entered, 'ggit' will also show a brief summary of\n> the command what it will do when executed, explaining it's intended usage.\n> \n> Is the list correct, or did I miss something?\n> \n> \n> Thanks and regards,\n> Sidhant Sharma\n"},{"id":"281284","messageId":"56EEC6EE.10602@gmail.com","threadId":"41676","inReplyTo":"33EDD26C-ED5A-42EE-B523-240AEF5C51B7@gmail.com","subject":"Re: [RFC/GSoC] Introduction","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-03-20T15:51:10Z","receivedAt":"2016-03-20T15:51:10Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"On Sunday 20 March 2016 09:09 PM, Lars Schneider wrote:\n> Hi Sidhant,\n>\n> that sounds about right to me. In what language do you plan to implement the \n> wrapper?\nI'm comfortable in programming with C, so I think I can use that. Otherwise,\nI'm also comfortable with python and familiar with bash, if they are required.\nWould C be the right choice though?\nAlso, I've made a draft proposal for the project and uploaded to the GSoC\napplication site. Should I send it to the list as well for RFC?\n\nThanks,\nSidhant Sharma\n> Best,\n> Lars\n>\n> On 17 Mar 2016, at 15:52, Sidhant Sharma wrote:\n>\n>> Hi,\n>>\n>> So to sum up, the list of tasks for the project would be:\n>> 1. A wrapper is to be implemented around (called 'ggit') that will scan the\n>> arguments for potentially destructive commands. When none are found, all the\n>> arguments will simply be passed through to git.\n>> 2. If such a command is found, 'ggit' will:\n>> a. Show what the command is actually going to do.\n>> b. Ask the user if they are sure they want to execute it.\n>> Eg. \"You are about to do X which will permanently destroy Y. Do you want to\n>> continue?\"\n>> 3. For all commands that are entered, 'ggit' will also show a brief summary of\n>> the command what it will do when executed, explaining it's intended usage.\n>>\n>> Is the list correct, or did I miss something?\n>>\n>>\n>> Thanks and regards,\n>> Sidhant Sharma\n"},{"id":"281286","messageId":"A0465058-2171-4C00-8D45-C610046C496D@gmail.com","threadId":"41676","inReplyTo":"56EEC6EE.10602@gmail.com","subject":"Re: [RFC/GSoC] Introduction","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-03-20T16:08:46Z","receivedAt":"2016-03-20T16:08:46Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\nOn 20 Mar 2016, at 16:51, Sidhant Sharma wrote:\n\n> On Sunday 20 March 2016 09:09 PM, Lars Schneider wrote:\n>> Hi Sidhant,\n>> \n>> that sounds about right to me. In what language do you plan to implement the \n>> wrapper?\n> I'm comfortable in programming with C, so I think I can use that. Otherwise,\n> I'm also comfortable with python and familiar with bash, if they are required.\n> Would C be the right choice though?\n> Also, I've made a draft proposal for the project and uploaded to the GSoC\n> application site. Should I send it to the list as well for RFC?\n\nAlthough I like Python a lot, I don't think it would be a good choice. AFAIK Git\ncore does not depend on Python and therefore you can't really expect a Python\ninterpreter in every Git environment (e.g. it is not part of Git for Windows).\n\nThe wrapper could certainly be implemented in C, although I don't know if this \nwould make things harder then they need to be. My initial thought was to use a\nscripting language that is known to be shipped with Git (Bash or Perl). I\nthink Perl might even have an advantage as it offers very good regex/string\nprocessing functions (disclaimer: I am no Perl expert at all...).\n\nPlease post your draft proposal as plain text RFC to the list.\n\nThanks,\nLars\n\n\n> \n> Thanks,\n> Sidhant Sharma\n>> Best,\n>> Lars\n>> \n>> On 17 Mar 2016, at 15:52, Sidhant Sharma wrote:\n>> \n>>> Hi,\n>>> \n>>> So to sum up, the list of tasks for the project would be:\n>>> 1. A wrapper is to be implemented around (called 'ggit') that will scan the\n>>> arguments for potentially destructive commands. When none are found, all the\n>>> arguments will simply be passed through to git.\n>>> 2. If such a command is found, 'ggit' will:\n>>> a. Show what the command is actually going to do.\n>>> b. Ask the user if they are sure they want to execute it.\n>>> Eg. \"You are about to do X which will permanently destroy Y. Do you want to\n>>> continue?\"\n>>> 3. For all commands that are entered, 'ggit' will also show a brief summary of\n>>> the command what it will do when executed, explaining it's intended usage.\n>>> \n>>> Is the list correct, or did I miss something?\n>>> \n>>> \n>>> Thanks and regards,\n>>> Sidhant Sharma\n> \n"},{"id":"281287","messageId":"56EECE2E.4080004@gmail.com","threadId":"41676","inReplyTo":"A0465058-2171-4C00-8D45-C610046C496D@gmail.com","subject":"Re: [RFC/GSoC] Introduction","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-03-20T16:22:06Z","receivedAt":"2016-03-20T16:22:06Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"On Sunday 20 March 2016 09:38 PM, Lars Schneider wrote:\n> On 20 Mar 2016, at 16:51, Sidhant Sharma wrote:\n>\n>> On Sunday 20 March 2016 09:09 PM, Lars Schneider wrote:\n>>> Hi Sidhant,\n>>>\n>>> that sounds about right to me. In what language do you plan to implement the \n>>> wrapper?\n>> I'm comfortable in programming with C, so I think I can use that. Otherwise,\n>> I'm also comfortable with python and familiar with bash, if they are required.\n>> Would C be the right choice though?\n>> Also, I've made a draft proposal for the project and uploaded to the GSoC\n>> application site. Should I send it to the list as well for RFC?\n> Although I like Python a lot, I don't think it would be a good choice. AFAIK Git\n> core does not depend on Python and therefore you can't really expect a Python\n> interpreter in every Git environment (e.g. it is not part of Git for Windows).\n>\n> The wrapper could certainly be implemented in C, although I don't know if this \n> would make things harder then they need to be. My initial thought was to use a\n> scripting language that is known to be shipped with Git (Bash or Perl). I\n> think Perl might even have an advantage as it offers very good regex/string\n> processing functions (disclaimer: I am no Perl expert at all...).\nOkay, I'll get started with Perl right away, shouldn't take long.\n> Please post your draft proposal as plain text RFC to the list.\n>\n> Thanks,\n> Lars\n>\n>\n>> Thanks,\n>> Sidhant Sharma\n>>> Best,\n>>> Lars\n>>>\n>>> On 17 Mar 2016, at 15:52, Sidhant Sharma wrote:\n>>>\n>>>> Hi,\n>>>>\n>>>> So to sum up, the list of tasks for the project would be:\n>>>> 1. A wrapper is to be implemented around (called 'ggit') that will scan the\n>>>> arguments for potentially destructive commands. When none are found, all the\n>>>> arguments will simply be passed through to git.\n>>>> 2. If such a command is found, 'ggit' will:\n>>>> a. Show what the command is actually going to do.\n>>>> b. Ask the user if they are sure they want to execute it.\n>>>> Eg. \"You are about to do X which will permanently destroy Y. Do you want to\n>>>> continue?\"\n>>>> 3. For all commands that are entered, 'ggit' will also show a brief summary of\n>>>> the command what it will do when executed, explaining it's intended usage.\n>>>>\n>>>> Is the list correct, or did I miss something?\n>>>>\n>>>>\n>>>> Thanks and regards,\n>>>> Sidhant Sharma\n"},{"id":"281307","messageId":"vpqwpow9a4o.fsf@anie.imag.fr","threadId":"41676","inReplyTo":"56E6DF17.2040106@gmail.com","subject":"Re: [RFC/GSoC] Introduction","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-03-20T20:17:59Z","receivedAt":"2016-03-20T20:17:59Z","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 14 March 2016 01:46 PM, Lars Schneider wrote:\n>\n>> I also thought about (2). The obvious advantage of having something like \n>> \"ggit\" as part of Git core is that it would be shipped with the standard\n>> Git distribution. That would especially help beginners.\n\nYes. And that would allow any tutorial to start with something like\n\"Since you're a beginner, use the command ggit instead of git. When\nyou're confident enough, just drop the first 'g' and continue hacking.\"\n\nAsking a beginner to install a separate tool before starting is a show\nstopper to me. Or at least, it should be _very_ easy to install.\n\n> I understand that this endeavour may or may not be merged into\n> the official Git distribution (though I'd really like it to :)), but\n> I still wish to attempt this. I'm also eager to continue work on this\n> even after GSoC is over, so maintenance shouldn't be an issue ;)\n\nMy usual advice on this point (both for mentors and students): hope that\nyou will continue contributing after the end of the project, but plan as\nif you won't. You don't want the survival of your code to depend only on\nyou.\n\nI have experience similar to GSoC where I offer CS students to\ncontribute to open-source software as part of a school project. Almost\nall of them told me that they would continue after and essentially none\nof them did. I think at least most of them were sincere when they said\nthey would continue, but then they realize that days have only 24 hours\nand life is short ;-).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"281308","messageId":"vpqlh5c99md.fsf@anie.imag.fr","threadId":"41676","inReplyTo":"xmqq7fh5as54.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC/GSoC] Introduction","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-03-20T20:28:58Z","receivedAt":"2016-03-20T20:28:58Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Lars Schneider writes:\n>\n>> On 14 Mar 2016, at 07:57, Junio C Hamano wrote:\n>>\n>>> I recall back in the days when people said that Hg's command set was\n>>> so much more pleasant to use that some people thought about building\n>>> Hg's command line UI on top of low level implementation of the Git's\n>>> data structure....\n>>> ...\n>>\n>> I think a \"ggit\" wrapper should not introduce any new commands or\n>> new parameters. Everything should be passed unmodified to Git.\n>> The wrapper would only add additional warnings...\n>\n> Somehow I was assuming that you are aiming for a more ambitious\n> project, where the users get an easier-to-learn-and-understand\n> command line UI experience than bare Git [*1*],\n\nI think the proposed approach makes much more sense, at least because:\n\n* At some point, ggit users should become git users and the transition\n should be smooth.\n\n* ggit users will find advices/documentation/tutorials here and there on\n the web, or talk to their friends who use git, and they want this\n information to apply to ggit.\n\nAlso, having an alternative UI sometimes serves as an excuse not to\nimprove git's UI itself. If git's behavior is dangerous, ggit can warn\nabout it. If git's behavior is broken, then we should repair it.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"}]}