[PATCH] git-gui: Call do_quit before destroying the main window

[PATCH] git-gui: Call do_quit before destroying the main window

[Pratyush Yadav]

If the toplevel window for the window being destroyed is the main window
(aka "."), then simply destroying it means the cleanup tasks are not
executed like saving the commit message buffer, saving window state,
etc. All this is handled by do_quit so, call it instead of directly
destroying the main window. For other toplevel windows, the old behavior
remains.

Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
---
 git-gui/git-gui.sh | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 6de74ce639..6ec562d5da 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -3030,8 +3030,23 @@ unset doc_path doc_url
 wm protocol . WM_DELETE_WINDOW do_quit
 bind all <$M1B-Key-q> do_quit
 bind all <$M1B-Key-Q> do_quit
-bind all <$M1B-Key-w> {destroy [winfo toplevel %W]}
-bind all <$M1B-Key-W> {destroy [winfo toplevel %W]}
+
+set m1b_w_script {
+	set toplvl_win [winfo toplevel %W]
+
+	# If we are destroying the main window, we should call do_quit to take
+	# care of cleanup before exiting the program.
+	if {$toplvl_win eq "."} {
+		do_quit
+	} else {
+		destroy $toplvl_win
+	}
+}
+
+bind all <$M1B-Key-w> $m1b_w_script
+bind all <$M1B-Key-W> $m1b_w_script
+
+unset m1b_w_script
 
 set subcommand_args {}
 proc usage {} {
-- 
2.21.0

Re: [PATCH] git-gui: Call do_quit before destroying the main window

[Pratyush Yadav]

If there are no comments/objections with this patch, can it be merged 
please?

On 8/4/19 8:09 PM, Pratyush Yadav wrote:
> If the toplevel window for the window being destroyed is the main window
> (aka "."), then simply destroying it means the cleanup tasks are not
> executed like saving the commit message buffer, saving window state,
> etc. All this is handled by do_quit so, call it instead of directly
> destroying the main window. For other toplevel windows, the old behavior
> remains.
> 
> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
> ---
>   git-gui/git-gui.sh | 19 +++++++++++++++++--
>   1 file changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
> index 6de74ce639..6ec562d5da 100755
> --- a/git-gui/git-gui.sh
> +++ b/git-gui/git-gui.sh
> @@ -3030,8 +3030,23 @@ unset doc_path doc_url
>   wm protocol . WM_DELETE_WINDOW do_quit
>   bind all <$M1B-Key-q> do_quit
>   bind all <$M1B-Key-Q> do_quit
> -bind all <$M1B-Key-w> {destroy [winfo toplevel %W]}
> -bind all <$M1B-Key-W> {destroy [winfo toplevel %W]}
> +
> +set m1b_w_script {
> +	set toplvl_win [winfo toplevel %W]
> +
> +	# If we are destroying the main window, we should call do_quit to take
> +	# care of cleanup before exiting the program.
> +	if {$toplvl_win eq "."} {
> +		do_quit
> +	} else {
> +		destroy $toplvl_win
> +	}
> +}
> +
> +bind all <$M1B-Key-w> $m1b_w_script
> +bind all <$M1B-Key-W> $m1b_w_script
> +
> +unset m1b_w_script
>   
>   set subcommand_args {}
>   proc usage {} {
> 


-- 
Regards,
Pratyush Yadav

Re: [PATCH] git-gui: Call do_quit before destroying the main window

[Junio C Hamano]

Pratyush Yadav <me@yadavpratyush.com> writes:

> If there are no comments/objections with this patch, can it be merged
> please?

It usually works the other way around (no comments by default means
no interests), but sadly, a larger problem with this area is that
there currently is nobody who is actively working on maintaining the
'git-gui' project, which is a separate project that our tree merely
pulls from time to time.  So we need to find a volunteer to run that
project, send the patch in that direction and get it merged, and
then finally we can pull from them X-<.




>
> On 8/4/19 8:09 PM, Pratyush Yadav wrote:
>> If the toplevel window for the window being destroyed is the main window
>> (aka "."), then simply destroying it means the cleanup tasks are not
>> executed like saving the commit message buffer, saving window state,
>> etc. All this is handled by do_quit so, call it instead of directly
>> destroying the main window. For other toplevel windows, the old behavior
>> remains.
>>
>> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
>> ---
>>   git-gui/git-gui.sh | 19 +++++++++++++++++--
>>   1 file changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
>> index 6de74ce639..6ec562d5da 100755
>> --- a/git-gui/git-gui.sh
>> +++ b/git-gui/git-gui.sh
>> @@ -3030,8 +3030,23 @@ unset doc_path doc_url
>>   wm protocol . WM_DELETE_WINDOW do_quit
>>   bind all <$M1B-Key-q> do_quit
>>   bind all <$M1B-Key-Q> do_quit
>> -bind all <$M1B-Key-w> {destroy [winfo toplevel %W]}
>> -bind all <$M1B-Key-W> {destroy [winfo toplevel %W]}
>> +
>> +set m1b_w_script {
>> +	set toplvl_win [winfo toplevel %W]
>> +
>> +	# If we are destroying the main window, we should call do_quit to take
>> +	# care of cleanup before exiting the program.
>> +	if {$toplvl_win eq "."} {
>> +		do_quit
>> +	} else {
>> +		destroy $toplvl_win
>> +	}
>> +}
>> +
>> +bind all <$M1B-Key-w> $m1b_w_script
>> +bind all <$M1B-Key-W> $m1b_w_script
>> +
>> +unset m1b_w_script
>>     set subcommand_args {}
>>   proc usage {} {
>>

Re: [PATCH] git-gui: Call do_quit before destroying the main window

[Pratyush Yadav]

On 8/6/19 11:52 PM, Junio C Hamano wrote:
> Pratyush Yadav <me@yadavpratyush.com> writes:
> 
>> If there are no comments/objections with this patch, can it be merged
>> please?
> 
> It usually works the other way around (no comments by default means
> no interests), but sadly, a larger problem with this area is that
> there currently is nobody who is actively working on maintaining the
> 'git-gui' project, which is a separate project that our tree merely
> pulls from time to time.  So we need to find a volunteer to run that
> project, send the patch in that direction and get it merged, and
> then finally we can pull from them X-<.

I'm not too optimistic on finding someone to run this project. I asked 
on the list who the maintainer is [0], and no one came up. The repo at 
[1] also seems abandoned.

So if I fork the project, will you pull from my fork? If yes, what 
exactly would I have to do? Make a set of changes and then ask on the 
list for you to pull from my fork?

I am a relatively inexperienced programmer, and it feels like a kinda 
big responsibility that I'm not sure I am ready for. But maybe you can 
look at the changes from a high level POV before pulling, so there is 
someone sanity checking my changes.

[0] 
https://public-inbox.org/git/35506bd2-aae9-6608-ed4d-a408e0c831b8@yadavpratyush.com/
[1] https://repo.or.cz/w/git-gui.git/

> 
>>
>> On 8/4/19 8:09 PM, Pratyush Yadav wrote:
>>> If the toplevel window for the window being destroyed is the main window
>>> (aka "."), then simply destroying it means the cleanup tasks are not
>>> executed like saving the commit message buffer, saving window state,
>>> etc. All this is handled by do_quit so, call it instead of directly
>>> destroying the main window. For other toplevel windows, the old behavior
>>> remains.
>>>
>>> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
>>> ---
>>>    git-gui/git-gui.sh | 19 +++++++++++++++++--
>>>    1 file changed, 17 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
>>> index 6de74ce639..6ec562d5da 100755
>>> --- a/git-gui/git-gui.sh
>>> +++ b/git-gui/git-gui.sh
>>> @@ -3030,8 +3030,23 @@ unset doc_path doc_url
>>>    wm protocol . WM_DELETE_WINDOW do_quit
>>>    bind all <$M1B-Key-q> do_quit
>>>    bind all <$M1B-Key-Q> do_quit
>>> -bind all <$M1B-Key-w> {destroy [winfo toplevel %W]}
>>> -bind all <$M1B-Key-W> {destroy [winfo toplevel %W]}
>>> +
>>> +set m1b_w_script {
>>> +	set toplvl_win [winfo toplevel %W]
>>> +
>>> +	# If we are destroying the main window, we should call do_quit to take
>>> +	# care of cleanup before exiting the program.
>>> +	if {$toplvl_win eq "."} {
>>> +		do_quit
>>> +	} else {
>>> +		destroy $toplvl_win
>>> +	}
>>> +}
>>> +
>>> +bind all <$M1B-Key-w> $m1b_w_script
>>> +bind all <$M1B-Key-W> $m1b_w_script
>>> +
>>> +unset m1b_w_script
>>>      set subcommand_args {}
>>>    proc usage {} {
>>>


-- 
Regards,
Pratyush Yadav

Re: [PATCH] git-gui: Call do_quit before destroying the main window

[Junio C Hamano]

Pratyush Yadav <me@yadavpratyush.com> writes:

> I'm not too optimistic on finding someone to run this project. I asked
> on the list who the maintainer is [0], and no one came up. The repo at
> [1] also seems abandoned.

In the meantime until somebody steps up, I might run my own copy.

I need to allocate a block of time to see how stale Pat's tree is
(e.g. its mainline may have more commits than what we have pulled,
in which case we need to be extra careful---these old commits may be
something Pat found dubious and decided to wait before telling me to
pull, and we would be better off ignoring them) before I can say
anything definite, but I am hoping that there won't be too many
patches flowing to the git-gui project; anything high volume and/or
tricky tcl/tk would be beyond my capacity as an interim maintainer
to maintain the quality of the codebase of it.

Re: [PATCH] git-gui: Call do_quit before destroying the main window

[Junio C Hamano]

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

> Pratyush Yadav <me@yadavpratyush.com> writes:
>
>> I'm not too optimistic on finding someone to run this project. I asked
>> on the list who the maintainer is [0], and no one came up. The repo at
>> [1] also seems abandoned.
>
> In the meantime until somebody steps up, I might run my own copy.
>
> I need to allocate a block of time to see how stale Pat's tree is
> (e.g. its mainline may have more commits than what we have pulled,
> in which case we need to be extra careful---these old commits may be
> something Pat found dubious and decided to wait before telling me to
> pull, and we would be better off ignoring them) before I can say
> anything definite, but I am hoping that there won't be too many
> patches flowing to the git-gui project; anything high volume and/or
> tricky tcl/tk would be beyond my capacity as an interim maintainer
> to maintain the quality of the codebase of it.

Well it turns out that the clone I used a few years ago was still
usable X-<, so I made https://github.com/gitster/git-gui/ a
tentative and experimental home to pull from.  I munged the patch to
apply to the git-gui tree, create a topic there, pulled it via subtree
strategy to create a topic 'py/git-gui-do-quit' here, and queued the
result on 'pu'.

Re: [PATCH] git-gui: Call do_quit before destroying the main window

[Junio C Hamano]

Pratyush Yadav <me@yadavpratyush.com> writes:

> So if I fork the project, will you pull from my fork? If yes, what
> exactly would I have to do? Make a set of changes and then ask on the
> list for you to pull from my fork?
>
> I am a relatively inexperienced programmer, and it feels like a kinda
> big responsibility that I'm not sure I am ready for. But maybe you can
> look at the changes from a high level POV before pulling, so there is
> someone sanity checking my changes.

This patch as a one-off thing may not be too bad, as it already had
exposure to the list (and there probably are more people scanning it
than it would have been if you silently made a pull request on
GitHub, because they saw messages from me in this thread).

BUT.

If I make it a habit to pull git-gui stuff from random people who
are not committed to and/or feel experienced enough for working on
git-gui, the result would be even worse than taking patches on
git-gui directly from the list.  At least a patch on the list I can
see how others react (or not react).  On the other hand, I do not
know how to interpret lack of comments from others on GitHub pull
request---perhaps nobody thought it was a good change, perhaps
nobody is paying attention to it, or what other possibilities there
are.

So,... quite honestly, I'd rather not.

Re: [PATCH] git-gui: Call do_quit before destroying the main window

[Pratyush Yadav]

On 8/7/19 11:20 PM, Junio C Hamano wrote:
> Pratyush Yadav <me@yadavpratyush.com> writes:
> 
>> So if I fork the project, will you pull from my fork? If yes, what
>> exactly would I have to do? Make a set of changes and then ask on the
>> list for you to pull from my fork?
>>
>> I am a relatively inexperienced programmer, and it feels like a kinda
>> big responsibility that I'm not sure I am ready for. But maybe you can
>> look at the changes from a high level POV before pulling, so there is
>> someone sanity checking my changes.
> 
> This patch as a one-off thing may not be too bad, as it already had
> exposure to the list (and there probably are more people scanning it
> than it would have been if you silently made a pull request on
> GitHub, because they saw messages from me in this thread).

I think you misunderstood me. I do not mean to create a GitHub pull 
request, because as you say, no one other than me and you will look at 
it. What I meant was that I can pile up a bunch of commits, and send 
them on this list here for you to merge. I can explain those changes in 
the cover letter, so people not very familiar with git-gui or Tcl/Tk can 
still get a general idea of what's happening.

> BUT.
> 
> If I make it a habit to pull git-gui stuff from random people who
> are not committed to and/or feel experienced enough for working on
> git-gui, the result would be even worse than taking patches on
> git-gui directly from the list.  At least a patch on the list I can
> see how others react (or not react).  On the other hand, I do not
> know how to interpret lack of comments from others on GitHub pull
> request---perhaps nobody thought it was a good change, perhaps
> nobody is paying attention to it, or what other possibilities there
> are.
> 
> So,... quite honestly, I'd rather not.
> 

I'm not sure what the bottom line is for what you say. Does this mean 
that you'd rather not merge patches about git-gui at all, and if I want 
to improve something, I should just run my own fork (at least until 
someone steps up to maintain it)? Or does this mean that you'd prefer me 
to send patches here on this list, and you'd look at them and merge 
them? Or is it something else?

And again, to make it clear, I do not intend to use GitHub pull requests 
at all. What I meant by "pull from me" was just that you pull (maybe 
fetch is the right word?) changes from my fork and merge them in your 
tree. But as you said, you'd rather not.

-- 
Regards,
Pratyush Yadav

Re: [PATCH] git-gui: Call do_quit before destroying the main window

[Junio C Hamano]

Pratyush Yadav <me@yadavpratyush.com> writes:

> I think you misunderstood me. I do not mean to create a GitHub pull
> request, because as you say, no one other than me and you will look at
> it. What I meant was that I can pile up a bunch of commits, and send
> them on this list here for you to merge. I can explain those changes
> in the cover letter, so people not very familiar with git-gui or
> Tcl/Tk can still get a general idea of what's happening.

If you meant to volunteer to act as a git-gui maintainer, that would
be wonderful.  Then I do not have to play an interim maintainer.

Or did you mean to do that only for your own patches, forcing _me_
to become a de-facto interim maintainer for git-gui project?  You
effectively ended up doing so for this single patch already ;-)

I will not be able to continue doing so for anything more complex or
controversial, though.

Thanks.

Re: [PATCH] git-gui: Call do_quit before destroying the main window

[Pratyush Yadav]

On 8/8/19 3:23 AM, Junio C Hamano wrote:
> Pratyush Yadav <me@yadavpratyush.com> writes:
> 
>> I think you misunderstood me. I do not mean to create a GitHub pull
>> request, because as you say, no one other than me and you will look at
>> it. What I meant was that I can pile up a bunch of commits, and send
>> them on this list here for you to merge. I can explain those changes
>> in the cover letter, so people not very familiar with git-gui or
>> Tcl/Tk can still get a general idea of what's happening.
> 
> If you meant to volunteer to act as a git-gui maintainer, that would
> be wonderful.  Then I do not have to play an interim maintainer.

Yes, I do mean to volunteer to act as a git-gui maintainer.

Is there something I should know other than 
Documentation/howto/maintain-git.txt?

> Or did you mean to do that only for your own patches, forcing _me_
> to become a de-facto interim maintainer for git-gui project?  You
> effectively ended up doing so for this single patch already ;-)
> 
> I will not be able to continue doing so for anything more complex or
> controversial, though.
> 
> Thanks.
> 


-- 
Regards,
Pratyush Yadav

Re: [PATCH] git-gui: Call do_quit before destroying the main window

[Junio C Hamano]

Pratyush Yadav <me@yadavpratyush.com> writes:

>> If you meant to volunteer to act as a git-gui maintainer, that would
>> be wonderful.  Then I do not have to play an interim maintainer.
>
> Yes, I do mean to volunteer to act as a git-gui maintainer.
>
> Is there something I should know other than
> Documentation/howto/maintain-git.txt?

Well, I do not think that document has anything useful for being a
maintainer for git-gui in it.

The Git community members needs to be able to trust that the new
Git-gui maintainer would make a sensible decision when picking up
(or asking to improve) a patch from the list to collect and forward
to me.  We somehow need to make sure that happens.

It also is nice if we can get the handing over the maintainership
endorsed by the current Git-gui maintainer.

Compared to that, the procedural issues (how the patches are
reviewed, when and how they are forwarded to me, etc.) are much less
important.

Re: [PATCH] git-gui: Call do_quit before destroying the main window

[Pratyush Yadav]

On 09/08/19 01:03PM, Junio C Hamano wrote:
> Pratyush Yadav <me@yadavpratyush.com> writes:
> 
> >> If you meant to volunteer to act as a git-gui maintainer, that would
> >> be wonderful.  Then I do not have to play an interim maintainer.
> >
> > Yes, I do mean to volunteer to act as a git-gui maintainer.
> >
> > Is there something I should know other than
> > Documentation/howto/maintain-git.txt?
> 
> Well, I do not think that document has anything useful for being a
> maintainer for git-gui in it.
> 
> The Git community members needs to be able to trust that the new
> Git-gui maintainer would make a sensible decision when picking up
> (or asking to improve) a patch from the list to collect and forward
> to me.  We somehow need to make sure that happens.
 
Yes, but how? Of course, I don't intend to run this thing into the 
ground. I want the project to be useful for everyone. I only recently 
got involved with the project, and so most people here don't know me or 
my work that well. Maybe me contributing to the main git project can 
help. But other than that, the only way to build that trust is with 
time.

> It also is nice if we can get the handing over the maintainership
> endorsed by the current Git-gui maintainer.

Well, Pat has not replied to your email, so I don't think that will be 
possible.

> Compared to that, the procedural issues (how the patches are
> reviewed, when and how they are forwarded to me, etc.) are much less
> important.

Of course. But knowing them doesn't hurt :).

[0] 
https://public-inbox.org/git/CAP8UFD1C_FD5TLz0oyn6QzGU2rdvvTe6PNhpK29vkMfuHim-qg@mail.gmail.com/

-- 
Regards,
Pratyush Yadav

Re: [PATCH] git-gui: Call do_quit before destroying the main window

[Junio C Hamano]

Pratyush Yadav <me@yadavpratyush.com> writes:

>> The Git community members needs to be able to trust that the new
>> Git-gui maintainer would make a sensible decision when picking up
>> (or asking to improve) a patch from the list to collect and forward
>> to me.  We somehow need to make sure that happens.
>  
> Yes, but how? ...
> ... the only way to build that trust is with 
> time.

Yup, you got it right.  Trust needs to be earned and we need to
start from somewhere ;-)