[RFC/GSoC] Introduction

[RFC/GSoC] Introduction

[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

Re: [RFC/GSoC] Introduction

[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 :-)

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 <tigerkid001@gmail.com> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/GSoC] Introduction

[Sidhant Sharma]

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 <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

Re: [RFC/GSoC] Introduction

[Kevin Daudt]

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 <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.

Re: [RFC/GSoC] Introduction

[Sidhant Sharma]

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 <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.
Thanks, I'll add that one too. Also, should git checkout -- <file> be
added, since it'll discard all uncommitted changes?

Regards,
Sidhant Sharma

Re: [RFC/GSoC] Introduction

[Jacob Keller]

On Sun, Mar 13, 2016 at 10:25 PM, Sidhant Sharma <tigerkid001@gmail.com> 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

Re: [RFC/GSoC] Introduction

[Junio C Hamano]

Kevin Daudt <me@ikke.info> 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 <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.

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.

Re: [RFC/GSoC] Introduction

[Jacob Keller]

On Sun, Mar 13, 2016 at 11:33 AM, Sidhant Sharma <tigerkid001@gmail.com> 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

Re: [RFC/GSoC] Introduction

[Sidhant Sharma]

On Monday 14 March 2016 04:58 AM, Jacob Keller wrote:
> On Sun, Mar 13, 2016 at 11:33 AM, Sidhant Sharma <tigerkid001@gmail.com> 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

Re: [RFC/GSoC] Introduction

[Jacob Keller]

On Sun, Mar 13, 2016 at 10:25 PM, Sidhant Sharma <tigerkid001@gmail.com> wrote:
>
> On Monday 14 March 2016 04:58 AM, Jacob Keller wrote:
>> On Sun, Mar 13, 2016 at 11:33 AM, Sidhant Sharma <tigerkid001@gmail.com> 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

Re: [RFC/GSoC] Introduction

[Sidhant Sharma]

On Monday 14 March 2016 11:44 AM, Jacob Keller wrote:
> On Sun, Mar 13, 2016 at 10:25 PM, Sidhant Sharma <tigerkid001@gmail.com> 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

Re: [RFC/GSoC] Introduction

[Junio C Hamano]

Lars Schneider <larsxschneider@gmail.com> 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.

Re: [RFC/GSoC] Introduction

[Lars Schneider]

On 14 Mar 2016, at 07:57, Junio C Hamano <gitster@pobox.com> wrote:

> Lars Schneider <larsxschneider@gmail.com> 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?

Re: [RFC/GSoC] Introduction

[Sidhant Sharma]

On Monday 14 March 2016 01:46 PM, Lars Schneider wrote:
> On 14 Mar 2016, at 07:57, Junio C Hamano <gitster@pobox.com> 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

Re: [RFC/GSoC] Introduction

[Matthieu Moy]

Sidhant Sharma <tigerkid001@gmail.com> 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/

Re: [RFC/GSoC] Introduction

[Junio C Hamano]

Lars Schneider <larsxschneider@gmail.com> writes:

> On 14 Mar 2016, at 07:57, Junio C Hamano <gitster@pobox.com> 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".

Re: [RFC/GSoC] Introduction

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> Lars Schneider <larsxschneider@gmail.com> writes:
>
>> On 14 Mar 2016, at 07:57, Junio C Hamano <gitster@pobox.com> 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/

Re: [RFC/GSoC] Introduction

[Philip Oakley]

From: "Lars Schneider" <larsxschneider@gmail.com>
>
> On 14 Mar 2016, at 07:57, Junio C Hamano <gitster@pobox.com> wrote:
>
>> Lars Schneider <larsxschneider@gmail.com> 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 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [RFC/GSoC] Introduction

[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

Re: [RFC/GSoC] Introduction

[Lars Schneider]

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 <tigerkid001@gmail.com> 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

Re: [RFC/GSoC] Introduction

[Sidhant Sharma]

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 <tigerkid001@gmail.com> 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

Re: [RFC/GSoC] Introduction

[Lars Schneider]

On 20 Mar 2016, at 16:51, Sidhant Sharma <tigerkid001@gmail.com> 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 <tigerkid001@gmail.com> 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
> 

Re: [RFC/GSoC] Introduction

[Sidhant Sharma]

On Sunday 20 March 2016 09:38 PM, Lars Schneider wrote:
> On 20 Mar 2016, at 16:51, Sidhant Sharma <tigerkid001@gmail.com> 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 <tigerkid001@gmail.com> 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

Re: [RFC/GSoC] Introduction

[Philip Oakley]

From: "Philip Oakley" <philipoakley@iee.org> Sent: March 14, 2016 9:08 PM
> From: "Lars Schneider" <larsxschneider@gmail.com>
>>
>> On 14 Mar 2016, at 07:57, Junio C Hamano <gitster@pobox.com> wrote:
>>
>>> Lars Schneider <larsxschneider@gmail.com> 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 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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>