Introduction
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
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
Quoted 33 lines · Sidhant Sharma
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 8 lines · Lars Schneider
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 :)
Quoted 11 lines
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
ggitas a safety net.
Quoted 2 lines
I am curious about your opinions on this kind of approach. I wonder if people would actually use such a wrapper.
Coincidentally, my approach too is a wrapper around git as you suggest. The approach is simple and straight forward, but I wasn't sure if it would be accepted on the list, mainly because it may not look consistent with the current interface git command [options]. Perhaps a configuration like core.beginnerMode [4] might be apt? By default, it can be false, making git behave normally. When set, a safety-check can be run before the command is executed to ensure it's not potentially destructive. Very much like a wrapper but on the inside. There can be an option like --no-beginner to override this configuration from the command-line. I was wondering if there should be command-specific options as well, such as beginner.allowForcePush, beginner.allowRebase etc. for a finer control over what commands git would warn the user about. By default, all are set to false, and warning is shown when any of them is encountered. Another configuration that may be considered is beginner.strict, which when set would just print the warning and die, instead of giving the user an option to continue (though I'm a little unsure whether this one would be a good idea).
One thing that bothers me about this approach is that unlike the explicit 'ggit' wrapper, an internal wrapper would add (unnecessary?) overhead for most commands, thus impacting the performance. Will that be an issue?
Along with this, the idea of showing a short instruction for undoing commands sounds very nice as it'll help beginners to understand and use git better.
I'm eager to know your opinions on this approach :)
Other than this, I also tried to expand the list of potentially destructive commands and updated the list as follows (additions in brackets):
* git rebase [ git pull --rebase ]
* git reset --hard
* git clean -f
* git gc --prune=now --aggressive
* git push -f [ git push <remote> :<branch>, git push <remote> +<branch> ]
* [ git branch -D ]
Are these additions appropriate? What other commands should be included?
Thanks and regards,
Sidhant Sharma
[4]: http://thread.gmane.org/gmane.comp.version-control.git/285893/focus=286663
Quoted 6 lines · Sidhant Sharma
Other than this, I also tried to expand the list of potentially destructive commands and updated the list as follows (additions in brackets):
Quoted 10 lines
* git rebase [ git pull --rebase ]
* git reset --hard
* git clean -f
* git gc --prune=now --aggressive
* git push -f [ git push <remote> :<branch>, git push <remote> +<branch> ]
* [ git branch -D ]Are these additions appropriate? What other commands should be included?
git checkout [ref] <file> is destructive too if it would overwrite an uncomitted change.
Quoted 11 lines · Kevin Daudt
Quoted 10 lines · Sidhant Sharma
Other than this, I also tried to expand the list of potentially destructive commands and updated the list as follows (additions in brackets):
* git rebase [ git pull --rebase ]
* git reset --hard
* git clean -f
* git gc --prune=now --aggressive
* git push -f [ git push <remote> :<branch>, git push <remote> +<branch> ]
* [ git branch -D ]
Quoted 4 lines
Quoted 2 lines
Are these additions appropriate? What other commands should be included?
git checkout [ref] <file> is destructive too if it would overwrite an uncomitted change.
Thanks, I'll add that one too. Also, should git checkout -- <file> be added, since it'll discard all uncommitted changes?
Regards,
Sidhant Sharma
Quoted 7 lines · Sidhant Sharma
Quoted 5 lines · Kevin Daudt
Quoted 4 lines · Sidhant Sharma
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
Quoted 14 lines · Kevin Daudt
Quoted 13 lines · Sidhant Sharma
Other than this, I also tried to expand the list of potentially destructive commands and updated the list as follows (additions in brackets):
* git rebase [ git pull --rebase ]
* git reset --hard
* git clean -f
* git gc --prune=now --aggressive
* git push -f [ git push <remote> :<branch>, git push <remote> +<branch> ]
* [ git branch -D ]
Quoted 4 lines
Quoted 1 line
Are these additions appropriate? What other commands should be included?
git checkout [ref] <file> 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 <file>" is destructive if it overwrites the index entry that holds contents you have not committed.
"git rm [--cached] <file>" is destructive, too.
I think "git checkout [<ref>] <file>" falls into the same category.
Quoted 11 lines · Sidhant Sharma
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 likecore.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-beginnerto override this configuration from the command-line. I was wondering if there should be command-specific options as well, such asbeginner.allowForcePush,beginner.allowRebaseetc. for a finer control over what commands git would warn
Quoted 9 lines
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
Quoted 21 lines · Jacob Keller
Quoted 11 lines · Sidhant Sharma
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 likecore.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-beginnerto override this configuration from the command-line. I was wondering if there should be command-specific options as well, such asbeginner.allowForcePush,beginner.allowRebaseetc. for a finer control over what commands git would warnQuoted 9 lines
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?
Quoted 6 lines
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
Quoted 36 lines · Sidhant Sharma
Quoted 21 lines · Jacob Keller
Quoted 11 lines · Sidhant Sharma
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 likecore.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-beginnerto override this configuration from the command-line. I was wondering if there should be command-specific options as well, such asbeginner.allowForcePush,beginner.allowRebaseetc. for a finer control over what commands git would warnQuoted 9 lines
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?Quoted 6 lines
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-beginnerto all such commands wouldn't be right. In that case, can we have the flag between git and the command? Such asgit --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?
Quoted 3 lines
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
Quoted 40 lines · Jacob Keller
Quoted 15 lines · Sidhant Sharma
Quoted 7 lines · Jacob Keller
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-beginnerto all such commands wouldn't be right. In that case, can we have the flag between git and the command? Such asgit --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?Quoted 3 lines
Thanks and regards,
Sidhant SharmaNo, 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.
Quoted 5 lines
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
Quoted 4 lines · Lars Schneider
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.
Quoted 18 lines · Junio C Hamano
Quoted 4 lines · Lars Schneider
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".
Quoted 8 lines
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.
Quoted 10 lines
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.
Quoted 3 lines
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?
Quoted 11 lines · Lars Schneider
Quoted 3 lines · Junio C Hamano
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.
Quoted 7 lines
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).
Quoted 22 lines
Quoted 11 lines
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.
Quoted 3 lines
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.
Quoted 7 lines
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
Quoted 5 lines · Sidhant Sharma
Quoted 3 lines · Lars Schneider
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.
Quoted 4 lines
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 ;-).
Signature · 2 lines
Matthieu Moy http://www-verimag.imag.fr/~moy/
Quoted 11 lines · Lars Schneider
Quoted 5 lines · Junio C Hamano
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.
Quoted 7 lines
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".
Quoted 10 lines · Junio C Hamano
Quoted 8 lines · Lars Schneider
Quoted 5 lines · Junio C Hamano
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....
...
Quoted 7 lines
Quoted 3 lines
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.
Signature · 2 lines
Matthieu Moy http://www-verimag.imag.fr/~moy/
From: "Lars Schneider" <[email protected]>
Quoted 36 lines · Junio C Hamano
Quoted 19 lines
Quoted 4 lines · Lars Schneider
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".
Quoted 8 lines
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.
Quoted 5 lines
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.
Quoted 3 lines
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.
Quoted 37 lines
Quoted 12 lines
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.
Quoted 3 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
Hi Sidhant,
that sounds about right to me. In what language do you plan to implement the wrapper?
Best,
Lars
Quoted 19 lines · Sidhant Sharma
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
Quoted 4 lines · Lars Schneider
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
Quoted 24 lines
Best,
LarsQuoted 19 lines · Sidhant Sharma
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
Quoted 10 lines · Sidhant Sharma
Quoted 4 lines · Lars Schneider
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
Quoted 28 lines
Thanks,
Sidhant SharmaQuoted 24 lines
Best,
LarsQuoted 19 lines · Sidhant Sharma
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
Quoted 16 lines · Lars Schneider
Quoted 10 lines · Sidhant Sharma
Quoted 4 lines · Lars Schneider
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).
Quoted 5 lines
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.
Quoted 32 lines
Please post your draft proposal as plain text RFC to the list.
Thanks,
LarsQuoted 26 lines
Thanks,
Sidhant SharmaQuoted 24 lines
Best,
LarsQuoted 19 lines · Sidhant Sharma
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