Re: [RFC/GSoC] Introduction
From: "Philip Oakley" Sent: March 14, 2016 9:08 PM From: "Lars Schneider" On 14 Mar 2016, at 07:57, Junio C Hamano wrote: Lars Schneider writes: I thought a while about this requirement and I wonder if a wrapper called 'ggit' (guarded Git) could be a solution. The wrapper would pass all command line arguments to 'git' and check for potentially destructive commands. If such a command is detected then the user would see a warning. I recall back in the days when people said that Hg's command set was so much more pleasant to use that some people thought about building Hg's command line UI on top of low level implementation of the Git's data structure. Even before that time, there was an effort "Cogito" to build an alternate UI on top of Git core. If "ggit" can be made reasonably feature complete in such a way that it lets beginners do all what they need to do, omitting many advanced/hairy features core Git may let users use (i.e. making trade-off between power and risk of misuse differently from core Git), that may be a reasonable way to offer a "beginner mode". The beauty of such an approach is that as long as "ggit" correctly talks the same on-wire protocol when interacting with other people's repositories, nobody needs to even know or care that you are using "ggit" exclusively. Two systems can talk without problems. If "ggit" is made too limited, there is an issue. Beginners may at some point need to transition to the real thing to fully exploit the power of Git, and they may need to unlearn "ggit" and learn Git. I think a "ggit" wrapper should not introduce any new commands or new parameters. Everything should be passed unmodified to Git. The wrapper would only add additional warnings such as "You are about to do X which will permanently destroy Y. Do you want to continue?". Therefore a transition from "ggit" to "git" would not require any learning effort. Maybe "ggit" could also be interpreted as "guided Git" (sounds more friendly than "guarded Git"). I have the impression that many Git beginners make mistakes because they don't have a mental model of Git, yet. A "guided" Git version could explain the commands a bit more detailed as they use Git (e.g. with ASCII graph examples). +1 on "guided" as a softer more (beginner) friendly term. I know that's what man pages are for but I've encountered many users (especially on Windows) that are not aware of man pages. In previous discussion it has been said that that (teaching and explaining) is not the purpose of man pages. Rather, the man pages are for reference for those who already have a reasonable idea of what they are doing, and use the man page to check on details. Whether the man pages should have more examples (or a makefile option to include them) may be part of the beginner mode mix, and may come out of (or go into) the guidance examples. The Git data model is very powerful and it does take a lot of 'unlearning' of old expectations (which is very hard) before the capabilities of the git model become well established in the users mind. For example, remote tracking branches are not remote but local, and are a reverse polish description (a local branch which keeps track of a remote's branch, from the last time you looked). This just came up on the $gmane/289454 thread "When does git check for branch-X being uptodate with origin/branch-X?" (21 Mar '16). In that case, the issue was that the 'tracking' is not active, instead it's a passive status that can become out of date, resulting in confusion about the true status. This also is a issue because of the lack of a common, in a broad world view, set of words for the problem. Perhaps a 'have you fetched recently?' could be added for the beginner mode. Different people get different parts of the model in different orders and different rates. Identifying the many issues (in model understanding) may be a start for identifying which command/options should be targeted. This approach, if it wants to become successful in helping users, would take quite a lot of thinking and work to avoid omitting too much to necessitate users to migrate to Git. But I can very well imagine that a new "Cogito 2" project (I am not saying that the UI Cogito tried to achieve were superiour or anything of that sort--I just needed a name, and picked one name that came to my mind) may get done by those who interact rarely with the core Git community and may live as one of many independent and viable third-party projects you find on GitHub. There however are two questions I do not offhand have good answers to: (1) if that kind of effort is of suitable size for GSoC, and (2) if it is suitable to be supported by the Git project proper. Good questions. I have no previous experience with GSoC Git projects and therefore I am not qualified for an answer. However, my gut feeling would be that a proof of concept implementation of a "ggit" wrapper that does not add any new commands and only
Re: [RFC/GSoC] Introduction
Junio C Hamano writes: > Lars Schneider writes: > >> On 14 Mar 2016, at 07:57, Junio C Hamano wrote: >> >>> I recall back in the days when people said that Hg's command set was >>> so much more pleasant to use that some people thought about building >>> Hg's command line UI on top of low level implementation of the Git's >>> data structure >>> ... >> >> I think a "ggit" wrapper should not introduce any new commands or >> new parameters. Everything should be passed unmodified to Git. >> The wrapper would only add additional warnings... > > Somehow I was assuming that you are aiming for a more ambitious > project, where the users get an easier-to-learn-and-understand > command line UI experience than bare Git [*1*], I think the proposed approach makes much more sense, at least because: * At some point, ggit users should become git users and the transition should be smooth. * ggit users will find advices/documentation/tutorials here and there on the web, or talk to their friends who use git, and they want this information to apply to ggit. Also, having an alternative UI sometimes serves as an excuse not to improve git's UI itself. If git's behavior is dangerous, ggit can warn about it. If git's behavior is broken, then we should repair it. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/GSoC] Introduction
Sidhant Sharma writes: > On Monday 14 March 2016 01:46 PM, Lars Schneider wrote: > >> I also thought about (2). The obvious advantage of having something like >> "ggit" as part of Git core is that it would be shipped with the standard >> Git distribution. That would especially help beginners. Yes. And that would allow any tutorial to start with something like "Since you're a beginner, use the command ggit instead of git. When you're confident enough, just drop the first 'g' and continue hacking." Asking a beginner to install a separate tool before starting is a show stopper to me. Or at least, it should be _very_ easy to install. > I understand that this endeavour may or may not be merged into > the official Git distribution (though I'd really like it to :)), but > I still wish to attempt this. I'm also eager to continue work on this > even after GSoC is over, so maintenance shouldn't be an issue ;) My usual advice on this point (both for mentors and students): hope that you will continue contributing after the end of the project, but plan as if you won't. You don't want the survival of your code to depend only on you. I have experience similar to GSoC where I offer CS students to contribute to open-source software as part of a school project. Almost all of them told me that they would continue after and essentially none of them did. I think at least most of them were sincere when they said they would continue, but then they realize that days have only 24 hours and life is short ;-). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/GSoC] Introduction
On Sunday 20 March 2016 09:38 PM, Lars Schneider wrote: > On 20 Mar 2016, at 16:51, Sidhant Sharma wrote: > >> On Sunday 20 March 2016 09:09 PM, Lars Schneider wrote: >>> Hi Sidhant, >>> >>> that sounds about right to me. In what language do you plan to implement >>> the >>> wrapper? >> I'm comfortable in programming with C, so I think I can use that. Otherwise, >> I'm also comfortable with python and familiar with bash, if they are >> required. >> Would C be the right choice though? >> Also, I've made a draft proposal for the project and uploaded to the GSoC >> application site. Should I send it to the list as well for RFC? > Although I like Python a lot, I don't think it would be a good choice. AFAIK > Git > core does not depend on Python and therefore you can't really expect a Python > interpreter in every Git environment (e.g. it is not part of Git for Windows). > > The wrapper could certainly be implemented in C, although I don't know if > this > would make things harder then they need to be. My initial thought was to use a > scripting language that is known to be shipped with Git (Bash or Perl). I > think Perl might even have an advantage as it offers very good regex/string > processing functions (disclaimer: I am no Perl expert at all...). Okay, I'll get started with Perl right away, shouldn't take long. > Please post your draft proposal as plain text RFC to the list. > > Thanks, > Lars > > >> Thanks, >> Sidhant Sharma >>> Best, >>> Lars >>> >>> On 17 Mar 2016, at 15:52, Sidhant Sharma wrote: >>> Hi, So to sum up, the list of tasks for the project would be: 1. A wrapper is to be implemented around (called 'ggit') that will scan the arguments for potentially destructive commands. When none are found, all the arguments will simply be passed through to git. 2. If such a command is found, 'ggit' will: a. Show what the command is actually going to do. b. Ask the user if they are sure they want to execute it. Eg. "You are about to do X which will permanently destroy Y. Do you want to continue?" 3. For all commands that are entered, 'ggit' will also show a brief summary of the command what it will do when executed, explaining it's intended usage. Is the list correct, or did I miss something? Thanks and regards, Sidhant Sharma -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/GSoC] Introduction
On 20 Mar 2016, at 16:51, Sidhant Sharma wrote: > On Sunday 20 March 2016 09:09 PM, Lars Schneider wrote: >> Hi Sidhant, >> >> that sounds about right to me. In what language do you plan to implement the >> wrapper? > I'm comfortable in programming with C, so I think I can use that. Otherwise, > I'm also comfortable with python and familiar with bash, if they are required. > Would C be the right choice though? > Also, I've made a draft proposal for the project and uploaded to the GSoC > application site. Should I send it to the list as well for RFC? Although I like Python a lot, I don't think it would be a good choice. AFAIK Git core does not depend on Python and therefore you can't really expect a Python interpreter in every Git environment (e.g. it is not part of Git for Windows). The wrapper could certainly be implemented in C, although I don't know if this would make things harder then they need to be. My initial thought was to use a scripting language that is known to be shipped with Git (Bash or Perl). I think Perl might even have an advantage as it offers very good regex/string processing functions (disclaimer: I am no Perl expert at all...). Please post your draft proposal as plain text RFC to the list. Thanks, Lars > > Thanks, > Sidhant Sharma >> Best, >> Lars >> >> On 17 Mar 2016, at 15:52, Sidhant Sharma wrote: >> >>> Hi, >>> >>> So to sum up, the list of tasks for the project would be: >>> 1. A wrapper is to be implemented around (called 'ggit') that will scan the >>> arguments for potentially destructive commands. When none are found, all the >>> arguments will simply be passed through to git. >>> 2. If such a command is found, 'ggit' will: >>> a. Show what the command is actually going to do. >>> b. Ask the user if they are sure they want to execute it. >>> Eg. "You are about to do X which will permanently destroy Y. Do you want to >>> continue?" >>> 3. For all commands that are entered, 'ggit' will also show a brief summary >>> of >>> the command what it will do when executed, explaining it's intended usage. >>> >>> Is the list correct, or did I miss something? >>> >>> >>> Thanks and regards, >>> Sidhant Sharma > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/GSoC] Introduction
On Sunday 20 March 2016 09:09 PM, Lars Schneider wrote: > Hi Sidhant, > > that sounds about right to me. In what language do you plan to implement the > wrapper? I'm comfortable in programming with C, so I think I can use that. Otherwise, I'm also comfortable with python and familiar with bash, if they are required. Would C be the right choice though? Also, I've made a draft proposal for the project and uploaded to the GSoC application site. Should I send it to the list as well for RFC? Thanks, Sidhant Sharma > Best, > Lars > > On 17 Mar 2016, at 15:52, Sidhant Sharma wrote: > >> Hi, >> >> So to sum up, the list of tasks for the project would be: >> 1. A wrapper is to be implemented around (called 'ggit') that will scan the >> arguments for potentially destructive commands. When none are found, all the >> arguments will simply be passed through to git. >> 2. If such a command is found, 'ggit' will: >>a. Show what the command is actually going to do. >>b. Ask the user if they are sure they want to execute it. >> Eg. "You are about to do X which will permanently destroy Y. Do you want to >> continue?" >> 3. For all commands that are entered, 'ggit' will also show a brief summary >> of >> the command what it will do when executed, explaining it's intended usage. >> >> Is the list correct, or did I miss something? >> >> >> Thanks and regards, >> Sidhant Sharma -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/GSoC] Introduction
Hi Sidhant, that sounds about right to me. In what language do you plan to implement the wrapper? Best, Lars On 17 Mar 2016, at 15:52, Sidhant Sharma wrote: > Hi, > > So to sum up, the list of tasks for the project would be: > 1. A wrapper is to be implemented around (called 'ggit') that will scan the > arguments for potentially destructive commands. When none are found, all the > arguments will simply be passed through to git. > 2. If such a command is found, 'ggit' will: >a. Show what the command is actually going to do. >b. Ask the user if they are sure they want to execute it. > Eg. "You are about to do X which will permanently destroy Y. Do you want to > continue?" > 3. For all commands that are entered, 'ggit' will also show a brief summary of > the command what it will do when executed, explaining it's intended usage. > > Is the list correct, or did I miss something? > > > Thanks and regards, > Sidhant Sharma -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/GSoC] Introduction
Hi, So to sum up, the list of tasks for the project would be: 1. A wrapper is to be implemented around (called 'ggit') that will scan the arguments for potentially destructive commands. When none are found, all the arguments will simply be passed through to git. 2. If such a command is found, 'ggit' will: a. Show what the command is actually going to do. b. Ask the user if they are sure they want to execute it. Eg. "You are about to do X which will permanently destroy Y. Do you want to continue?" 3. For all commands that are entered, 'ggit' will also show a brief summary of the command what it will do when executed, explaining it's intended usage. Is the list correct, or did I miss something? Thanks and regards, Sidhant Sharma -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/GSoC] Introduction
From: "Lars Schneider" On 14 Mar 2016, at 07:57, Junio C Hamano wrote: Lars Schneider writes: I thought a while about this requirement and I wonder if a wrapper called 'ggit' (guarded Git) could be a solution. The wrapper would pass all command line arguments to 'git' and check for potentially destructive commands. If such a command is detected then the user would see a warning. I recall back in the days when people said that Hg's command set was so much more pleasant to use that some people thought about building Hg's command line UI on top of low level implementation of the Git's data structure. Even before that time, there was an effort "Cogito" to build an alternate UI on top of Git core. If "ggit" can be made reasonably feature complete in such a way that it lets beginners do all what they need to do, omitting many advanced/hairy features core Git may let users use (i.e. making trade-off between power and risk of misuse differently from core Git), that may be a reasonable way to offer a "beginner mode". The beauty of such an approach is that as long as "ggit" correctly talks the same on-wire protocol when interacting with other people's repositories, nobody needs to even know or care that you are using "ggit" exclusively. Two systems can talk without problems. If "ggit" is made too limited, there is an issue. Beginners may at some point need to transition to the real thing to fully exploit the power of Git, and they may need to unlearn "ggit" and learn Git. I think a "ggit" wrapper should not introduce any new commands or new parameters. Everything should be passed unmodified to Git. The wrapper would only add additional warnings such as "You are about to do X which will permanently destroy Y. Do you want to continue?". Therefore a transition from "ggit" to "git" would not require any learning effort. Maybe "ggit" could also be interpreted as "guided Git" (sounds more friendly than "guarded Git"). I have the impression that many Git beginners make mistakes because they don't have a mental model of Git, yet. A "guided" Git version could explain the commands a bit more detailed as they use Git (e.g. with ASCII graph examples). +1 on "guided" as a softer more (beginner) friendly term. I know that's what man pages are for but I've encountered many users (especially on Windows) that are not aware of man pages. In previous discussion it has been said that that (teaching and explaining) is not the purpose of man pages. Rather, the man pages are for reference for those who already have a reasonable idea of what they are doing, and use the man page to check on details. Whether the man pages should have more examples (or a makefile option to include them) may be part of the beginner mode mix, and may come out of (or go into) the guidance examples. The Git data model is very powerful and it does take a lot of 'unlearning' of old expectations (which is very hard) before the capabilities of the git model become well established in the users mind. For example, remote tracking branches are not remote but local, and are a reverse polish description (a local branch which keeps track of a remote's branch, from the last time you looked). Different people get different parts of the model in different orders and different rates. Identifying the many issues (in model understanding) may be a start for identifying which command/options should be targeted. This approach, if it wants to become successful in helping users, would take quite a lot of thinking and work to avoid omitting too much to necessitate users to migrate to Git. But I can very well imagine that a new "Cogito 2" project (I am not saying that the UI Cogito tried to achieve were superiour or anything of that sort--I just needed a name, and picked one name that came to my mind) may get done by those who interact rarely with the core Git community and may live as one of many independent and viable third-party projects you find on GitHub. There however are two questions I do not offhand have good answers to: (1) if that kind of effort is of suitable size for GSoC, and (2) if it is suitable to be supported by the Git project proper. Good questions. I have no previous experience with GSoC Git projects and therefore I am not qualified for an answer. However, my gut feeling would be that a proof of concept implementation of a "ggit" wrapper that does not add any new commands and only adds warnings for destructive commands could be in the GSoC scope. However, Sidhant must be aware of the fact that this is a controversial topic and therefore any future work on this topic might be never merged into Git. I also thought about (2). The obvious advantage of having something like "ggit" as part of Git core is that it would be shipped with the standard Git distribution. That would especially help beginners. However, maintenance is a very strong counter argument. Maybe "ggit" could start as a separate project and
Re: [RFC/GSoC] Introduction
Lars Schneider writes: > On 14 Mar 2016, at 07:57, Junio C Hamano wrote: > >> I recall back in the days when people said that Hg's command set was >> so much more pleasant to use that some people thought about building >> Hg's command line UI on top of low level implementation of the Git's >> data structure >> ... > > I think a "ggit" wrapper should not introduce any new commands or > new parameters. Everything should be passed unmodified to Git. > The wrapper would only add additional warnings... Somehow I was assuming that you are aiming for a more ambitious project, where the users get an easier-to-learn-and-understand command line UI experience than bare Git [*1*], but none of what I said about "limiting and omitting" applies if "ggit" will be a "passthru after examining what goes on" wrapper. > Maybe "ggit" could also be interpreted as "guided Git" (sounds more > friendly than "guarded Git"). I have the impression that many Git > beginners make mistakes because they don't have a mental model of Git, > yet. A "guided" Git version could explain the commands a bit more > detailed as they use Git (e.g. with ASCII graph examples). I know > that's what man pages are for but I've encountered many users > (especially on Windows) that are not aware of man pages. ounds like a lot of work but still a sensible goal. And that leaves no room for questioning if it is suitable for Git GSOC, at least to me--it does fall into the scope of making experience of learning better for Git itself. Thanks. [Footnote] *1* For example, subversion migrants may say it is confusing to call the command "checkout" that is used to clobber files in the working tree to the state in the index and may want to call it "revert"--and "$SCM revert $path" would be the way the more ambitious project would let its users do that operation; it would call underlying "git checkout $path" for its users. There are other command line UI restructuring that will not belong to Git itself but an alternative UI front-end may want to use, e.g. "$SCM diff INDEX WORKTREE $pathname" that is turned into "git diff $pathname" and "$SCM diff HEAD INDEX $pathname" that is turned into "git diff --cached HEAD $pathname". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/GSoC] Introduction
On Monday 14 March 2016 11:44 AM, Jacob Keller wrote: > On Sun, Mar 13, 2016 at 10:25 PM, Sidhant Sharma > wrote: >> On Monday 14 March 2016 04:58 AM, Jacob Keller wrote: >>> >>> If I recall correctly, a configuration setting was previously >>> discussed but mostly discarded as a solution since any changes had >>> better not impact any current scripts. Having to add "--no-beginner" >>> for all of them seems unacceptable. Especially since many scripts may >>> do potentially dangerous operations in a safe or useful way. >>> >> I agree that adding `--no-beginner` to all such commands wouldn't be right. >> In >> that case, can we have the flag between git and the command? Such as >> `git --no-beginner reset --hard`. If present, the flag can then be removed >> from >> the argument list and the rest of the command executed as is without warning. >> Would that a better option? >> >> >> Thanks and regards, >> Sidhant Sharma >> > No, the whole problem with "--no-beginner" is that scripts must either > check the configuration variable or add the flag. Since, by definition > exactly zero scripts do that today, then every script must either (a) > be re-written, (b) accept that some behavior will not work as > expected. > > Most (robust) scripts will already check for aliases, and if not, the > user should expect that doing weird things to their environment in > this way would cause things to break. > > I don't think we can create a design where scripts must be re-written > to protect themselves or accept misbehaving in those ways. > > If we had a clear (used) delineation between porcelain and plumbing > commands, we could have all the porcelain commands accept an argument > but not plumbing. Except that (a) all plumbing commands can be called > from the path relatively easily so a user might still want protection > on those too and (b) we don't actually have an enforced > plumbing/porcelain distinction. While we document one, several scripts > exist in the wild which violate this and which we may want to support. > > I think that we could go this route, but we'd have to be willing to > accept (a) or (b), above as costs to this route. Personally I prefer > the wrapper approach since it neatly bypasses all of this behavior and > seems easier to implement. It's major downside is telling beginners > to use "ggit" or similar, which is a big deal. Thanks for elaborating on that. I now understand why the configuration option approach is not fit. The 'ggit' wrapper does sound more apt for this. I do realize telling the beginners to use 'ggit' instead of just 'git' is a shortcoming of this approach, but perhaps it's worth it if it makes Git easier to use and understand for beginners. Lars' suggestion of short instructions would be really nice for helping beginners form a mental picture of git workflow, and might be worth the trade-off. Thanks and regards, Sidhant Sharma -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/GSoC] Introduction
On Monday 14 March 2016 01:46 PM, Lars Schneider wrote: > On 14 Mar 2016, at 07:57, Junio C Hamano wrote: > >> If "ggit" is made too limited, there is an issue. Beginners may at >> some point need to transition to the real thing to fully exploit the >> power of Git, and they may need to unlearn "ggit" and learn Git. > I think a "ggit" wrapper should not introduce any new commands or new > parameters. Everything should be passed unmodified to Git. The wrapper > would only add additional warnings such as "You are about to do X which > will permanently destroy Y. Do you want to continue?". Therefore > a transition from "ggit" to "git" would not require any learning effort. > > Maybe "ggit" could also be interpreted as "guided Git" (sounds more > friendly than "guarded Git"). I have the impression that many Git > beginners make mistakes because they don't have a mental model of Git, > yet. A "guided" Git version could explain the commands a bit more > detailed as they use Git (e.g. with ASCII graph examples). I know > that's what man pages are for but I've encountered many users > (especially on Windows) that are not aware of man pages. I too think that the wrapper should only pass on commands to git if they aren't potentially destructive, and not itself introduce new commands, unless there is a need (I doubt if there will be). > >> This approach, if it wants to become successful in helping users, >> would take quite a lot of thinking and work to avoid omitting too >> much to necessitate users to migrate to Git. But I can very well >> imagine that a new "Cogito 2" project (I am not saying that the UI >> Cogito tried to achieve were superiour or anything of that sort--I >> just needed a name, and picked one name that came to my mind) may >> get done by those who interact rarely with the core Git community >> and may live as one of many independent and viable third-party >> projects you find on GitHub. >> >> There however are two questions I do not offhand have good answers >> to: (1) if that kind of effort is of suitable size for GSoC, and (2) >> if it is suitable to be supported by the Git project proper. > Good questions. I have no previous experience with GSoC Git projects > and therefore I am not qualified for an answer. However, my gut feeling > would be that a proof of concept implementation of a "ggit" wrapper > that does not add any new commands and only adds warnings for destructive > commands could be in the GSoC scope. However, Sidhant must be aware of > the fact that this is a controversial topic and therefore any future work > on this topic might be never merged into Git. > > I also thought about (2). The obvious advantage of having something like > "ggit" as part of Git core is that it would be shipped with the standard > Git distribution. That would especially help beginners. However, > maintenance is a very strong counter argument. Maybe "ggit" could > start as a separate project and if it picks up then Git core can still > decide to merge it? > I understand that this endeavour may or may not be merged into the official Git distribution (though I'd really like it to :)), but I still wish to attempt this. I'm also eager to continue work on this even after GSoC is over, so maintenance shouldn't be an issue ;) Thanks and regards, Sidhant Sharma -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/GSoC] Introduction
On 14 Mar 2016, at 07:57, Junio C Hamano wrote: > Lars Schneider writes: > >> I thought a while about this requirement and I wonder if a wrapper called >> 'ggit' (guarded Git) could be a solution. The wrapper would pass all >> command line arguments to 'git' and check for potentially destructive >> commands. If such a command is detected then the user would see a warning. > > I recall back in the days when people said that Hg's command set was > so much more pleasant to use that some people thought about building > Hg's command line UI on top of low level implementation of the Git's > data structure. Even before that time, there was an effort "Cogito" > to build an alternate UI on top of Git core. If "ggit" can be made > reasonably feature complete in such a way that it lets beginners do > all what they need to do, omitting many advanced/hairy features core > Git may let users use (i.e. making trade-off between power and risk > of misuse differently from core Git), that may be a reasonable way > to offer a "beginner mode". > > The beauty of such an approach is that as long as "ggit" correctly > talks the same on-wire protocol when interacting with other people's > repositories, nobody needs to even know or care that you are using > "ggit" exclusively. Two systems can talk without problems. > > If "ggit" is made too limited, there is an issue. Beginners may at > some point need to transition to the real thing to fully exploit the > power of Git, and they may need to unlearn "ggit" and learn Git. I think a "ggit" wrapper should not introduce any new commands or new parameters. Everything should be passed unmodified to Git. The wrapper would only add additional warnings such as "You are about to do X which will permanently destroy Y. Do you want to continue?". Therefore a transition from "ggit" to "git" would not require any learning effort. Maybe "ggit" could also be interpreted as "guided Git" (sounds more friendly than "guarded Git"). I have the impression that many Git beginners make mistakes because they don't have a mental model of Git, yet. A "guided" Git version could explain the commands a bit more detailed as they use Git (e.g. with ASCII graph examples). I know that's what man pages are for but I've encountered many users (especially on Windows) that are not aware of man pages. > This approach, if it wants to become successful in helping users, > would take quite a lot of thinking and work to avoid omitting too > much to necessitate users to migrate to Git. But I can very well > imagine that a new "Cogito 2" project (I am not saying that the UI > Cogito tried to achieve were superiour or anything of that sort--I > just needed a name, and picked one name that came to my mind) may > get done by those who interact rarely with the core Git community > and may live as one of many independent and viable third-party > projects you find on GitHub. > > There however are two questions I do not offhand have good answers > to: (1) if that kind of effort is of suitable size for GSoC, and (2) > if it is suitable to be supported by the Git project proper. Good questions. I have no previous experience with GSoC Git projects and therefore I am not qualified for an answer. However, my gut feeling would be that a proof of concept implementation of a "ggit" wrapper that does not add any new commands and only adds warnings for destructive commands could be in the GSoC scope. However, Sidhant must be aware of the fact that this is a controversial topic and therefore any future work on this topic might be never merged into Git. I also thought about (2). The obvious advantage of having something like "ggit" as part of Git core is that it would be shipped with the standard Git distribution. That would especially help beginners. However, maintenance is a very strong counter argument. Maybe "ggit" could start as a separate project and if it picks up then Git core can still decide to merge it? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/GSoC] Introduction
Kevin Daudt writes: > On Mon, Mar 14, 2016 at 12:03:33AM +0530, Sidhant Sharma wrote: >> >> >> >> Other than this, I also tried to expand the list of potentially destructive >> commands and updated the list as follows (additions in brackets): >> >> * git rebase [ git pull --rebase ] >> * git reset --hard >> * git clean -f >> * git gc --prune=now --aggressive >> * git push -f [ git push :, git push + ] >> * [ git branch -D ] >> >> Are these additions appropriate? What other commands should be included? > > git checkout [ref] is destructive too if it would overwrite an > uncomitted change. Obviously. As that was designed to be the way to get rid of unsuccessful/unwanted edit in the working tree. "git add " is destructive if it overwrites the index entry that holds contents you have not committed. "git rm [--cached] " is destructive, too. I think "git checkout [] " falls into the same category. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/GSoC] Introduction
Lars Schneider writes: > I thought a while about this requirement and I wonder if a wrapper called > 'ggit' (guarded Git) could be a solution. The wrapper would pass all > command line arguments to 'git' and check for potentially destructive > commands. If such a command is detected then the user would see a warning. I recall back in the days when people said that Hg's command set was so much more pleasant to use that some people thought about building Hg's command line UI on top of low level implementation of the Git's data structure. Even before that time, there was an effort "Cogito" to build an alternate UI on top of Git core. If "ggit" can be made reasonably feature complete in such a way that it lets beginners do all what they need to do, omitting many advanced/hairy features core Git may let users use (i.e. making trade-off between power and risk of misuse differently from core Git), that may be a reasonable way to offer a "beginner mode". The beauty of such an approach is that as long as "ggit" correctly talks the same on-wire protocol when interacting with other people's repositories, nobody needs to even know or care that you are using "ggit" exclusively. Two systems can talk without problems. If "ggit" is made too limited, there is an issue. Beginners may at some point need to transition to the real thing to fully exploit the power of Git, and they may need to unlearn "ggit" and learn Git. This approach, if it wants to become successful in helping users, would take quite a lot of thinking and work to avoid omitting too much to necessitate users to migrate to Git. But I can very well imagine that a new "Cogito 2" project (I am not saying that the UI Cogito tried to achieve were superiour or anything of that sort--I just needed a name, and picked one name that came to my mind) may get done by those who interact rarely with the core Git community and may live as one of many independent and viable third-party projects you find on GitHub. There however are two questions I do not offhand have good answers to: (1) if that kind of effort is of suitable size for GSoC, and (2) if it is suitable to be supported by the Git project proper. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/GSoC] Introduction
On Sun, Mar 13, 2016 at 10:25 PM, Sidhant Sharma wrote: > > On Monday 14 March 2016 02:49 AM, Kevin Daudt wrote: >> On Mon, Mar 14, 2016 at 12:03:33AM +0530, Sidhant Sharma wrote: >>> Other than this, I also tried to expand the list of potentially destructive >>> commands and updated the list as follows (additions in brackets): >>> >>> * git rebase [ git pull --rebase ] For rebase, it is tricky since many work flows and setups use it a lot in ways that aren't a problem. Ideally we'd be able to warn about cases where it is very bad, but not in cases where it isn't likely to cause problems. It may be that it isn't possible to programatically determine this though. Regards, Jake -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/GSoC] Introduction
On Sun, Mar 13, 2016 at 10:25 PM, Sidhant Sharma wrote: > > On Monday 14 March 2016 04:58 AM, Jacob Keller wrote: >> On Sun, Mar 13, 2016 at 11:33 AM, Sidhant Sharma >> wrote: >>> Coincidentally, my approach too is a wrapper around git as you suggest. >>> The approach is simple and straight forward, but I wasn't sure if it would >>> be >>> accepted on the list, mainly because it may not look consistent with the >>> current >>> interface `git command [options]`. Perhaps a configuration like >>> `core.beginnerMode` [4] might be apt? By default, it can be false, making >>> git >>> behave normally. When set, a safety-check can be run before the command is >>> executed to ensure it's not potentially destructive. Very much like a >>> wrapper >>> but on the inside. There can be an option like `--no-beginner` to override >>> this configuration from the command-line. I was wondering if there should be >>> command-specific options as well, such as `beginner.allowForcePush`, >>> `beginner.allowRebase` etc. for a finer control over what commands git >>> would warn >>> the user about. By default, all are set to false, and warning is shown when >>> any >>> of them is encountered. Another configuration that may be considered is >>> `beginner.strict`, which when set would just print the warning and die, >>> instead >>> of giving the user an option to continue (though I'm a little unsure whether >>> this one would be a good idea). >>> One thing that bothers me about this approach is that unlike the explicit >>> 'ggit' >>> wrapper, an internal wrapper would add (unnecessary?) overhead for most >>> commands, >>> thus impacting the performance. Will that be an issue? >>> >> If I recall correctly, a configuration setting was previously >> discussed but mostly discarded as a solution since any changes had >> better not impact any current scripts. Having to add "--no-beginner" >> for all of them seems unacceptable. Especially since many scripts may >> do potentially dangerous operations in a safe or useful way. >> > I agree that adding `--no-beginner` to all such commands wouldn't be right. In > that case, can we have the flag between git and the command? Such as > `git --no-beginner reset --hard`. If present, the flag can then be removed > from > the argument list and the rest of the command executed as is without warning. > Would that a better option? > > > Thanks and regards, > Sidhant Sharma > No, the whole problem with "--no-beginner" is that scripts must either check the configuration variable or add the flag. Since, by definition exactly zero scripts do that today, then every script must either (a) be re-written, (b) accept that some behavior will not work as expected. Most (robust) scripts will already check for aliases, and if not, the user should expect that doing weird things to their environment in this way would cause things to break. I don't think we can create a design where scripts must be re-written to protect themselves or accept misbehaving in those ways. If we had a clear (used) delineation between porcelain and plumbing commands, we could have all the porcelain commands accept an argument but not plumbing. Except that (a) all plumbing commands can be called from the path relatively easily so a user might still want protection on those too and (b) we don't actually have an enforced plumbing/porcelain distinction. While we document one, several scripts exist in the wild which violate this and which we may want to support. I think that we could go this route, but we'd have to be willing to accept (a) or (b), above as costs to this route. Personally I prefer the wrapper approach since it neatly bypasses all of this behavior and seems easier to implement. It's major downside is telling beginners to use "ggit" or similar, which is a big deal. We have broken scripts in the past or changed behavior of commands before. But it is done using a phased transition with lots of warnings. It is possible that the gain is large enough to be worth it. In this case, I think we should heavily way that side because helping people learn git is a huge win. I can't count how many times I've had to tell someone "you really didn't mean to do that" and wished for a way to help avoid this. But, it is a cost to adding an option that any scripting, push/pull hooks or other complex workflows would have to be thought through carefully. Thanks, Jake -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/GSoC] Introduction
On Monday 14 March 2016 02:49 AM, Kevin Daudt wrote: > On Mon, Mar 14, 2016 at 12:03:33AM +0530, Sidhant Sharma wrote: >> Other than this, I also tried to expand the list of potentially destructive >> commands and updated the list as follows (additions in brackets): >> >> * git rebase [ git pull --rebase ] >> * git reset --hard >> * git clean -f >> * git gc --prune=now --aggressive >> * git push -f [ git push :, git push + ] >> * [ git branch -D ] >> >> Are these additions appropriate? What other commands should be included? >> > git checkout [ref] is destructive too if it would overwrite an > uncomitted change. Thanks, I'll add that one too. Also, should git checkout -- be added, since it'll discard all uncommitted changes? Regards, Sidhant Sharma -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/GSoC] Introduction
On Monday 14 March 2016 04:58 AM, Jacob Keller wrote: > On Sun, Mar 13, 2016 at 11:33 AM, Sidhant Sharma > wrote: >> Coincidentally, my approach too is a wrapper around git as you suggest. >> The approach is simple and straight forward, but I wasn't sure if it would be >> accepted on the list, mainly because it may not look consistent with the >> current >> interface `git command [options]`. Perhaps a configuration like >> `core.beginnerMode` [4] might be apt? By default, it can be false, making git >> behave normally. When set, a safety-check can be run before the command is >> executed to ensure it's not potentially destructive. Very much like a wrapper >> but on the inside. There can be an option like `--no-beginner` to override >> this configuration from the command-line. I was wondering if there should be >> command-specific options as well, such as `beginner.allowForcePush`, >> `beginner.allowRebase` etc. for a finer control over what commands git would >> warn >> the user about. By default, all are set to false, and warning is shown when >> any >> of them is encountered. Another configuration that may be considered is >> `beginner.strict`, which when set would just print the warning and die, >> instead >> of giving the user an option to continue (though I'm a little unsure whether >> this one would be a good idea). >> One thing that bothers me about this approach is that unlike the explicit >> 'ggit' >> wrapper, an internal wrapper would add (unnecessary?) overhead for most >> commands, >> thus impacting the performance. Will that be an issue? >> > If I recall correctly, a configuration setting was previously > discussed but mostly discarded as a solution since any changes had > better not impact any current scripts. Having to add "--no-beginner" > for all of them seems unacceptable. Especially since many scripts may > do potentially dangerous operations in a safe or useful way. > I agree that adding `--no-beginner` to all such commands wouldn't be right. In that case, can we have the flag between git and the command? Such as `git --no-beginner reset --hard`. If present, the flag can then be removed from the argument list and the rest of the command executed as is without warning. Would that a better option? Thanks and regards, Sidhant Sharma -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/GSoC] Introduction
On Sun, Mar 13, 2016 at 11:33 AM, Sidhant Sharma wrote: > Coincidentally, my approach too is a wrapper around git as you suggest. > The approach is simple and straight forward, but I wasn't sure if it would be > accepted on the list, mainly because it may not look consistent with the > current > interface `git command [options]`. Perhaps a configuration like > `core.beginnerMode` [4] might be apt? By default, it can be false, making git > behave normally. When set, a safety-check can be run before the command is > executed to ensure it's not potentially destructive. Very much like a wrapper > but on the inside. There can be an option like `--no-beginner` to override > this configuration from the command-line. I was wondering if there should be > command-specific options as well, such as `beginner.allowForcePush`, > `beginner.allowRebase` etc. for a finer control over what commands git would > warn > the user about. By default, all are set to false, and warning is shown when > any > of them is encountered. Another configuration that may be considered is > `beginner.strict`, which when set would just print the warning and die, > instead > of giving the user an option to continue (though I'm a little unsure whether > this one would be a good idea). > One thing that bothers me about this approach is that unlike the explicit > 'ggit' > wrapper, an internal wrapper would add (unnecessary?) overhead for most > commands, > thus impacting the performance. Will that be an issue? > If I recall correctly, a configuration setting was previously discussed but mostly discarded as a solution since any changes had better not impact any current scripts. Having to add "--no-beginner" for all of them seems unacceptable. Especially since many scripts may do potentially dangerous operations in a safe or useful way. Thanks, Jake -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/GSoC] Introduction
On Mon, Mar 14, 2016 at 12:03:33AM +0530, Sidhant Sharma wrote: > > > > Other than this, I also tried to expand the list of potentially destructive > commands and updated the list as follows (additions in brackets): > > * git rebase [ git pull --rebase ] > * git reset --hard > * git clean -f > * git gc --prune=now --aggressive > * git push -f [ git push :, git push + ] > * [ git branch -D ] > > Are these additions appropriate? What other commands should be included? > > git checkout [ref] is destructive too if it would overwrite an uncomitted change. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/GSoC] Introduction
On Sunday 13 March 2016 09:20 PM, Lars Schneider wrote: > Hi Sidhant, > > thanks for your interest in the 'Git Beginner' mode topic. I completely > understand your motivation for the topic as your Git learning experience > matches mine. However, please be aware that this is no easy project. The > final implementation might be easy but it will require hard work to come > up with a design for the beginner mode that the list considers to accept. > That being said, I am eager to learn about your ideas on the topic :-) Hi, I understand that this project will require much effort to find an acceptable solution and I'm prepared for it. I'm very excited to take this one up :) > Based on my previous discussions with Junio [3] I think on of the most > important aspects is to ensure that Git does not become harder to use. > I thought a while about this requirement and I wonder if a wrapper called > 'ggit' (guarded Git) could be a solution. The wrapper would pass all > command line arguments to 'git' and check for potentially destructive > commands. If such a command is detected then the user would see a warning. > If the command is not destructive then 'ggit' would print a short instruction > how to "undo" it. The ordinary Git user would not be affected at all by the > wrapper. A novice Git user who is unsure about his/her command line > usage could use `ggit` as a safety net. > > I am curious about your opinions on this kind of approach. I wonder if > people would actually use such a wrapper. Coincidentally, my approach too is a wrapper around git as you suggest. The approach is simple and straight forward, but I wasn't sure if it would be accepted on the list, mainly because it may not look consistent with the current interface `git command [options]`. Perhaps a configuration like `core.beginnerMode` [4] might be apt? By default, it can be false, making git behave normally. When set, a safety-check can be run before the command is executed to ensure it's not potentially destructive. Very much like a wrapper but on the inside. There can be an option like `--no-beginner` to override this configuration from the command-line. I was wondering if there should be command-specific options as well, such as `beginner.allowForcePush`, `beginner.allowRebase` etc. for a finer control over what commands git would warn the user about. By default, all are set to false, and warning is shown when any of them is encountered. Another configuration that may be considered is `beginner.strict`, which when set would just print the warning and die, instead of giving the user an option to continue (though I'm a little unsure whether this one would be a good idea). One thing that bothers me about this approach is that unlike the explicit 'ggit' wrapper, an internal wrapper would add (unnecessary?) overhead for most commands, thus impacting the performance. Will that be an issue? Along with this, the idea of showing a short instruction for undoing commands sounds very nice as it'll help beginners to understand and use git better. I'm eager to know your opinions on this approach :) Other than this, I also tried to expand the list of potentially destructive commands and updated the list as follows (additions in brackets): * git rebase [ git pull --rebase ] * git reset --hard * git clean -f * git gc --prune=now --aggressive * git push -f [ git push :, git push + ] * [ git branch -D ] Are these additions appropriate? What other commands should be included? Thanks and regards, Sidhant Sharma [4]: http://thread.gmane.org/gmane.comp.version-control.git/285893/focus=286663 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/GSoC] Introduction
Hi Sidhant, thanks for your interest in the 'Git Beginner' mode topic. I completely understand your motivation for the topic as your Git learning experience matches mine. However, please be aware that this is no easy project. The final implementation might be easy but it will require hard work to come up with a design for the beginner mode that the list considers to accept. That being said, I am eager to learn about your ideas on the topic :-) Based on my previous discussions with Junio [3] I think on of the most important aspects is to ensure that Git does not become harder to use. I thought a while about this requirement and I wonder if a wrapper called 'ggit' (guarded Git) could be a solution. The wrapper would pass all command line arguments to 'git' and check for potentially destructive commands. If such a command is detected then the user would see a warning. If the command is not destructive then 'ggit' would print a short instruction how to "undo" it. The ordinary Git user would not be affected at all by the wrapper. A novice Git user who is unsure about his/her command line usage could use `ggit` as a safety net. I am curious about your opinions on this kind of approach. I wonder if people would actually use such a wrapper. Thanks, Lars [3] http://thread.gmane.org/gmane.comp.version-control.git/285893/focus=286749 On 12 Mar 2016, at 07:59, Sidhant Sharma wrote: > Hi everyone! > > I am Sidhant Sharma, from Delhi, India. I'm a third year Software Engineering > student at Delhi Technological University. I am looking to contribute to > Git via GSoC 2016. I have also worked on one of the microprojects [1]. I've > been using git for nearly two years now, and continue to be surprised by the > vast number of features this powerful DVCS possesses. I want to contribute to > Git because it has become a daily-use tool for me and it feels exciting to > be a part of the community that makes effective collaborative development > possible. > > I would like to work on the project titled 'Git Beginner mode', and have been > reading up the discussions that took place regarding this [2]. The reason I > wish > to take this project in particular is that when I initially started out with > Git, and was still discovering how things really worked, I sometimes felt the > need for some sort of safety-latch to keep me from making destructive and/or > irreversible changes. So, this project gives me the opportunity to implement > something on these lines for the future beginners. I believe a lot of > discussion > on the idea is due. I'm reading up on the commands that were mentioned on the > project page to better understand what the project entails, and trying to > design > a solution for this, without making git harder to use or getting in the user's > learning. I would really appreciate your comments, suggestions and critique on > this. > > Thanks and regards, > Sidhant Sharma > > [1]: http://thread.gmane.org/gmane.comp.version-control.git/288035 > [2]: > http://thread.gmane.org/gmane.comp.version-control.git/285893/focus=286613 > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
