On Fri, Aug 17, 2018 at 3:44 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Usually, I refrain from merging larger topics in 'next' down to > 'master' when we get close to -rc0, but I am wondering if it is > better to merge all of them to 'master', even the ones on the larger > and possibly undercooked side, expecting that we collectively spend > effort on hunting and fixing bugs in them during the pre-release > freeze period. If we were to go that route, I'd want everybody's > buy-in and I'll promise to ignore any shiny new toys that appear on > list that are not regression fixes to topics merged to 'master' > since the end of the previous cycle to make sure people are not > distracted. Speaking of releases, linux for example has some releases that are more stable than others, as most distros pick the same release for their 'stable' release, whereas the regular and new releases are just off of the latest release of linux. Would a similar model be an interesting thought to entertain? I guess I could buy into a few weeks of bug fixing. > * nd/config-blame-sort (2018-08-06) 1 commit [...] > * nd/no-extern (2018-08-03) 12 commits [...] Thanks Duy for these two series! I would have expected the no-extern series to have a bit of merge conflicts similar to sb/object-store-lookup as it touches a lot of headers, but so far this looks like smooth sailing? > * sb/submodule-cleanup (2018-08-16) 2 commits > (merged to 'next' on 2018-08-17 at ca9d8aaef4) > + builtin/submodule--helper: remove stray new line > + t7410: update to new style > > A few preliminary minor clean-ups in the area around submodules. > > Will merge to 'master'. Oh, that is the prologue of https://public-inbox.org/git/20180816023100.161626-1-sbeller@xxxxxxxxxx/ which I will resend to build on top. Given your question to hunt more bugs, I'd delay its resend until after the release. > > * ao/submodule-wo-gitmodules-checked-out (2018-08-14) 7 commits > - submodule: support reading .gitmodules even when it's not checked out > - t7506: clean up .gitmodules properly before setting up new scenario > - submodule: use the 'submodule--helper config' command > - submodule--helper: add a new 'config' subcommand > - t7411: be nicer to future tests and really clean things up > - submodule: factor out a config_set_in_gitmodules_file_gently function > - submodule: add a print_config_from_gitmodules() helper > > The submodule support has been updated to read from the blob at > HEAD:.gitmodules when the .gitmodules file is missing from the > working tree. > > I find the design a bit iffy in that our usual "missing in the > working tree? let's use the latest blob" fallback is to take it > from the index, not from the HEAD. I am not sure; why does it feel iffy? > * bw/submodule-name-to-dir (2018-08-10) 2 commits > In modern repository layout, the real body of a cloned submodule > repository is held in .git/modules/ of the superproject, indexed by > the submodule name. URLencode the submodule name before computing > the name of the directory to make sure they form a flat namespace. > > Will merge to 'next'. Cool! Is the discussion on top of it still going whether to use a new config for special cases or how we distinguish between a/b/ and a%2fb as submodule names? > * md/filter-trees (2018-08-16) 6 commits > - list-objects-filter: implement filter tree:0 > - revision: mark non-user-given objects instead > - rev-list: handle missing tree objects properly > - list-objects: always parse trees gently > - list-objects: refactor to process_tree_contents > - list-objects: store common func args in struct > > The "rev-list --filter" feature learned to exclude all trees via > "tree:0" filter. I gave this a read and think it is good to go. > * sb/config-write-fix (2018-08-08) 3 commits > (merged to 'next' on 2018-08-17 at 7d9c7ce81f) > + git-config: document accidental multi-line setting in deprecated syntax > + config: fix case sensitive subsection names on writing > + t1300: document current behavior of setting options > > Recent update to "git config" broke updating variable in a > subsection, which has been corrected. > > Will merge to 'master'. Thanks! > > > * sb/range-diff-colors (2018-08-14) 8 commits > - diff.c: rewrite emit_line_0 more understandably > - diff.c: omit check for line prefix in emit_line_0 > - diff: use emit_line_0 once per line > - diff.c: add set_sign to emit_line_0 > - diff.c: reorder arguments for emit_line_ws_markup > - diff.c: simplify caller of emit_line_0 > - t3206: add color test for range-diff --dual-color > - test_decode_color: understand FAINT and ITALIC > (this branch uses js/range-diff; is tangled with es/format-patch-rangediff.) > > The color output support for recently introduced "range-diff" > command got tweaked a bit. No, this series doesn't tweak the colored range-diff. This might be: Add more test coverage to colored range-diff and refactor the diff machinery to be more readable. The test coverage proves no user visible changes are made. The tweaking comes in on top of this via https://public-inbox.org/git/20180817204354.108625-1-sbeller@xxxxxxxxxx/ Thanks, Stefan
