Message ID | pull.766.v2.git.1612208747.gitgitgadget@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | Simple IPC Mechanism | expand |
"Jeff Hostetler via GitGitGadget" <gitgitgadget@gmail.com> writes: > Here is version 2 of my "Simple IPC" series and addresses the following > review comments: > ... > Junio C Hamano (1): > ci/install-depends: attempt to fix "brew cask" stuff Huh?
On 2/1/21 5:20 PM, Junio C Hamano wrote: > "Jeff Hostetler via GitGitGadget" <gitgitgadget@gmail.com> writes: > >> Here is version 2 of my "Simple IPC" series and addresses the following >> review comments: >> ... >> Junio C Hamano (1): >> ci/install-depends: attempt to fix "brew cask" stuff > > Huh? > Sorry. I had to prepend that one to the patch series to get the CI builds to run. I've been working rebased against "v2.30.0" and GitGitGadget references "master". Jeff
Hi Junio & Jeff, On Mon, 1 Feb 2021, Jeff Hostetler wrote: > On 2/1/21 5:20 PM, Junio C Hamano wrote: > > "Jeff Hostetler via GitGitGadget" <gitgitgadget@gmail.com> writes: > > > > > Here is version 2 of my "Simple IPC" series and addresses the following > > > review comments: > > > ... > > > Junio C Hamano (1): > > > ci/install-depends: attempt to fix "brew cask" stuff > > > > Huh? > > > > Sorry. I had to prepend that one to the patch series to get the > CI builds to run. I've been working rebased against "v2.30.0" and > GitGitGadget references "master". The idea being that we want to be able to merge this branch as-is into Git for Windows (and also into microsoft/git), and therefore do not want to base it on a later commit that is not reachable from git-for-windows/git's `main` branch. Maybe it is time to merge `jc/macos-install-dependencies-fix` down to `maint`? Then we could base Simple IPC/FSMonitor on `maint` instead, and would still have the benefit we want. Ciao, Dscho
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > The idea being that we want to be able to merge this branch as-is into Git > for Windows (and also into microsoft/git), and therefore do not want to > base it on a later commit that is not reachable from git-for-windows/git's > `main` branch. > > Maybe it is time to merge `jc/macos-install-dependencies-fix` down to > `maint`? Then we could base Simple IPC/FSMonitor on `maint` instead, and > would still have the benefit we want. Now you mention it, if we ever have an update to the current 'maint' branch, we'd trigger this known failure in macOS build without a good reason, even though we have a fix that has been in use on the 'master' and above. I definitely qshould merge the jc/macos-install-dependencies-fix topic down to 'maint' now. Are there other topics that deserve to be in 'maint' that are "obviously correct" people can think of? Thanks.
Hi Junio, On Thu, 4 Feb 2021, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > The idea being that we want to be able to merge this branch as-is into Git > > for Windows (and also into microsoft/git), and therefore do not want to > > base it on a later commit that is not reachable from git-for-windows/git's > > `main` branch. > > > > Maybe it is time to merge `jc/macos-install-dependencies-fix` down to > > `maint`? Then we could base Simple IPC/FSMonitor on `maint` instead, and > > would still have the benefit we want. > > Now you mention it, if we ever have an update to the current 'maint' > branch, we'd trigger this known failure in macOS build without a > good reason, even though we have a fix that has been in use on the > 'master' and above. > > I definitely qshould merge the jc/macos-install-dependencies-fix > topic down to 'maint' now. > > Are there other topics that deserve to be in 'maint' that are > "obviously correct" people can think of? I looked over the branches merged into `master` that are not in `maint`, and from a cursory look, these seem to be good candidates: - pk/subsub-fetch-fix-take-2 - rs/rebase-commit-validation - en/stash-apply-sparse-checkout - ds/for-each-repo-noopfix - pb/mergetool-tool-help-fix - jk/t5516-deflake - jc/macos-install-dependencies-fix - jk/forbid-lf-in-git-url - jk/log-cherry-pick-duplicate-patches - js/skip-dashed-built-ins-from-config-mak From a cursory look, it might seem as if ds/maintenance-prefetch-cleanup would also be a good candidate, but it is not based on `maint`, although it _does_ appear to fix an issue introduced in v2.30.0-rc0~23^2~8. There is another candidate that I am not _quite_ sure about: dl/p4-encode-after-kw-expansion. It _seems_ as if it would be good to apply on the maintenance train, but I am uncertain how important a bug fix it is. There are also a couple test updates that might be nice to have in `maint`: - nk/perf-fsmonitor-cleanup - mt/t4129-with-setgid-dir - ad/t4129-setfacl-target-fix Finally, there are documentation updates that I would probably merge, if I was tasked with updating `maint`: - ta/doc-typofix - pb/doc-modules-git-work-tree-typofix - jc/sign-off - vv/send-email-with-less-secure-apps-access - ug/doc-lose-dircache - ab/gettext-charset-comment-fix - bc/doc-status-short - tb/local-clone-race-doc - ab/fsck-doc-fix - jt/packfile-as-uri-doc Ciao, Dscho
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> Are there other topics that deserve to be in 'maint' that are >> "obviously correct" people can think of? > > I looked over the branches merged into `master` that are not in `maint`, > and from a cursory look, these seem to be good candidates: > ... > There are also a couple test updates that might be nice to have in > `maint`: > ... > Finally, there are documentation updates that I would probably merge, if I > was tasked with updating `maint`: > ... Your list more or less matches what the ML (merge later) script on the todo/ branch produces when it is fed the RelNotes (the script just greps for "merge laster to maint" comments and shows the result in way a bit easier to use for me). The ones that are in RelNotes but not in your list are ab/branch-sort # 7 (11 days ago) ar/t6016-modernise # 1 (3 weeks ago) dl/p4-encode-after-kw-expansion # 1 (3 weeks ago) fc/t6030-bisect-reset-removes-auxiliary-files # 1 (4 weeks ago) ma/doc-pack-format-varint-for-sizes # 1 (3 weeks ago) ma/more-opaque-lock-file # 5 (11 days ago) ma/t1300-cleanup # 3 (3 weeks ago) zh/arg-help-format # 2 (3 weeks ago) and I think all of them are safe to merge down. Thanks for being an independent source I can rely on to sanity check what is in RelNotes. Very much appreciated.