| Message ID | 20190804143919.10732-1-me@yadavpratyush.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | git-gui: Call do_quit before destroying the main window | expand |
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 {} { >
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 {} { >>
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 {} { >>>
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.
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'.
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.
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.
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.
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. >
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.
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/
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 ;-)
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 {} {
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(-)