| Message ID | pull.1469.git.1674559397.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | gitk: handle long command-lines | expand |
Hi Pau & Junio, this patch series saw a positive review from Junio (thank you! I know that you try to stay away from Tcl code, so I appreciate the effort very much), but apart from that it simply languished on the mailing list for more than two months now. Paul, is there anything I can do to help you integrate this into `gitk`? Or is it time to pass over `gitk` maintenance to the Git project? Ciao, Johannes On Tue, 24 Jan 2023, Johannes Schindelin via GitGitGadget wrote: > These patches have been cooking for such a long time in Git for Windows that > you might think they turned into broth. Yummy broth, to be sure. But broth. > 'Tis beyond time for the patches to make it upstream. > > Johannes Schindelin (1): > gitk: prevent overly long command lines > > Nico Rieck (1): > gitk: escape file paths before piping to git log > > gitk | 36 +++++++++++++++++++++++++++++++----- > 1 file changed, 31 insertions(+), 5 deletions(-) > > > base-commit: 465f03869ae11acd04abfa1b83c67879c867410c > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1469%2Fdscho%2Fgitk-long-cmdline-v1 > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1469/dscho/gitk-long-cmdline-v1 > Pull-Request: https://github.com/gitgitgadget/git/pull/1469 > -- > gitgitgadget >
On Mon, Mar 27, 2023 at 3:41 AM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > this patch series saw a positive review from Junio (thank you! I know that > you try to stay away from Tcl code, so I appreciate the effort very much), > but apart from that it simply languished on the mailing list for more than > two months now. Two months? My patch which contains an obvious fix [1] has been waiting almost two years. > Paul, is there anything I can do to help you integrate this into `gitk`? > Or is it time to pass over `gitk` maintenance to the Git project? Or just remove it from the Git codebase and maintain it elsewhere. [1] https://lore.kernel.org/git/20210505211846.1842824-1-felipe.contreras@gmail.com/
On 27/03/2023 10:17, Johannes Schindelin wrote: > Hi Pau & Junio, > > this patch series saw a positive review from Junio (thank you! I know that > you try to stay away from Tcl code, so I appreciate the effort very much), > but apart from that it simply languished on the mailing list for more than > two months now. > > Paul, is there anything I can do to help you integrate this into `gitk`? > Or is it time to pass over `gitk` maintenance to the Git project? > > Ciao, > Johannes I just tripped over this problem while trying to de-stack my Git backlog https://github.com/git-for-windows/git/issues/4408 "sdk gitk interaction". > > On Tue, 24 Jan 2023, Johannes Schindelin via GitGitGadget wrote: > >> These patches have been cooking for such a long time in Git for Windows that >> you might think they turned into broth. Yummy broth, to be sure. But broth. >> 'Tis beyond time for the patches to make it upstream. >> >> Johannes Schindelin (1): >> gitk: prevent overly long command lines >> >> Nico Rieck (1): >> gitk: escape file paths before piping to git log >> >> gitk | 36 +++++++++++++++++++++++++++++++----- >> 1 file changed, 31 insertions(+), 5 deletions(-) >> >> >> base-commit: 465f03869ae11acd04abfa1b83c67879c867410c >> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1469%2Fdscho%2Fgitk-long-cmdline-v1 >> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1469/dscho/gitk-long-cmdline-v1 >> Pull-Request: https://github.com/gitgitgadget/git/pull/1469 >> -- >> gitgitgadget >> If there was a way to un-stick this [1] it would be great. Philip [1] https://lore.kernel.org/git/pull.1469.git.1674559397.gitgitgadget@gmail.com/
Hello, Philip Oakley wrote: > On 27/03/2023 10:17, Johannes Schindelin wrote: > > Hi Pau & Junio, > > > > this patch series saw a positive review from Junio (thank you! I know that > > you try to stay away from Tcl code, so I appreciate the effort very much), > > but apart from that it simply languished on the mailing list for more than > > two months now. > > > > Paul, is there anything I can do to help you integrate this into `gitk`? > > Or is it time to pass over `gitk` maintenance to the Git project? > > I just tripped over this problem while trying to de-stack my Git backlog > https://github.com/git-for-windows/git/issues/4408 "sdk gitk interaction". > > > On Tue, 24 Jan 2023, Johannes Schindelin via GitGitGadget wrote: > > > >> These patches have been cooking for such a long time in Git for Windows that > >> you might think they turned into broth. Yummy broth, to be sure. But broth. > >> 'Tis beyond time for the patches to make it upstream. > > If there was a way to un-stick this [1] it would be great. One of the main selling points of git is that it was a *distributed* version control system, which means there wasn't any centralized repository. We are not forced to use Paul Mackerras' repository, so I created a fork that includes the outstanding patches [1]. Junio can simply pull from there from now on. I don't want to maintain this, but as I've often found out is the case in open source: if I don't do it, nobody else will. If anyone else wants to step up and maintain gitk, that would be great. Cheers. [1] https://github.com/felipec/gitk
Philip Oakley <philipoakley@iee.email> writes: > On 27/03/2023 10:17, Johannes Schindelin wrote: >> Hi Pau & Junio, >> >> this patch series saw a positive review from Junio (thank you! I know that >> you try to stay away from Tcl code, so I appreciate the effort very much), >> but apart from that it simply languished on the mailing list for more than >> two months now. >> >> Paul, is there anything I can do to help you integrate this into `gitk`? >> Or is it time to pass over `gitk` maintenance to the Git project? >> >> Ciao, >> Johannes > > I just tripped over this problem while trying to de-stack my Git backlog > https://github.com/git-for-windows/git/issues/4408 "sdk gitk interaction". I have done the same "create temporary fork of gitk, queue the patches, merge the result down while asking Paul to pull from me" dance I did every once in a while in the past (it seems the last I did it was in Sep 2019 [*]). * The last merge from Paulus is ef9b086d (Merge branch 'master' of git://git.ozlabs.org/~paulus/gitk, 2022-05-11), whose second parent (i.e. Paulus's tip) was 465f0386 (gitk: include y coord in recorded sash position, 2022-02-20). * The two patches that originate from GfW have been applied on top of 465f0386 in the gitk history; the result of this is 7dd272ec (gitk: escape file paths before piping to git log, 2023-01-24). * The js/gitk-fixes-from-gfw topic holds a -Xsubtree=gitk-git merge of 7dd272ec into my tree. This was merged to 'next' and hopefully will finish the usual 'next' to 'master' journey soonish. Paul, can you fetch js/gitk-fixes-from-gfw branch of https://github.com/gitster/git/, which will give you 7dd272ec that you can use to $ git merge 7dd272ec to obtain these two commits from Johannes and Nico? Alternatively, you can fetch 'seen' from any of the mirrors, as it hopefully should always contain that topic from now on. Thanks. [References] * https://lore.kernel.org/git/xmqqlfum7epn.fsf@gitster-ct.c.googlers.com/
Junio C Hamano wrote: > Philip Oakley <philipoakley@iee.email> writes: > > On 27/03/2023 10:17, Johannes Schindelin wrote: > >> Paul, is there anything I can do to help you integrate this into `gitk`? > >> Or is it time to pass over `gitk` maintenance to the Git project? > > > > I just tripped over this problem while trying to de-stack my Git backlog > > https://github.com/git-for-windows/git/issues/4408 "sdk gitk interaction". > * The two patches that originate from GfW have been applied on top > of 465f0386 in the gitk history; the result of this is 7dd272ec > (gitk: escape file paths before piping to git log, 2023-01-24). Why only those patches? Does patches signed off by GfW developers carry a special status regardless of their content?