On Wed, Mar 28, 2018 at 12:58 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > * ab/doc-hash-brokenness (2018-03-27) 2 commits > - doc hash-function-transition: clarify what SHAttered means > - doc hash-function-transition: clarify how older gits die on NewHash This looked ready for next to me. > > * jk/branch-l-0-deprecation (2018-03-26) 3 commits > - branch: deprecate "-l" option > - t: switch "branch -l" to "branch --create-reflog" > - t3200: unset core.logallrefupdates when testing reflog creation > (this branch is used by jk/branch-l-1-removal and jk/branch-l-2-reincarnation.) > > > * jk/branch-l-1-removal (2018-03-26) 1 commit > - branch: drop deprecated "-l" option > (this branch is used by jk/branch-l-2-reincarnation; uses jk/branch-l-0-deprecation.) > > > * jk/branch-l-2-reincarnation (2018-03-26) 1 commit > - branch: make "-l" a synonym for "--list" > (this branch uses jk/branch-l-0-deprecation and jk/branch-l-1-removal.) These three branches are interesting as all the work is done already. We just have to wait? Anyway the first step looks good to me. > * sb/blame-color (2018-02-13) 3 commits > - builtin/blame: highlight recently changed lines > - builtin/blame: add option to color metadata fields separately > - builtin/blame: dim uninteresting metadata > > Expecting a reroll. > cf. https://public-inbox.org/git/20171110011002.10179-1-sbeller@xxxxxxxxxx/#t > error messages are funny, can segfault, ... I look into that again, I thought I had fixed the segfaults last time. > * sb/object-store (2018-03-26) 27 commits ... > (this branch is used by sb/packfiles-in-repository; uses nd/remove-ignore-env-field.) > > Refactoring the internal global data structure to make it possible > to open multiple repositories, work with and then close them. > > Rerolled by Duy on top of a separate preliminary clean-up topic. > The resulting structure of the topics looked very sensible. > > Waiting for a follow-up discussion. I had the impression the discussion had settled and this would be ready for next. https://public-inbox.org/git/xmqqy3iebpsw.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx/ > * sb/packfiles-in-repository (2018-03-26) 12 commits ... > > (this branch uses nd/remove-ignore-env-field and sb/object-store.) > > Refactoring of the internal global data structure continues. > > Waiting for a follow-up discussion. I'll review this one more closely and start a discussion. > * bw/protocol-v2 (2018-03-15) 35 commits > > The beginning of the next-gen transfer protocol. > > Is everybody happy with this version? One design decision with > larger consequence "to or not to build in?" has been settled in > favor of status quo, IIRC. I skimmed over it and think it is ok to go. > * en/rename-directory-detection (2018-02-27) 29 commits > (merged to 'next' on 2018-03-06 at d42470f86e) ... > Rename detection logic in "diff" family that is used in "merge" has > learned to guess when all of x/a, x/b and x/c have moved to z/a, > z/b and z/c, it is likely that x/d added in the meantime would also > want to move to z/d by taking the hint that the entire directory > 'x' moved to 'z'. A bug causing dirty files involved in a rename > to be overwritten during merge has also been fixed as part of this > work. > > Will cook in 'next'. I am excited about this one, despite having an issue this week unrelated to this series, but related to rename detection. The issue was an apparent rename from a tiny .c to a .java file (also tiny), the license header was the large common part. I wonder if we want get away from counting the lines that are equal and instead want to go for some entropy based approach. (When the license shows up in many files, they will become boring) Another approach would be to give a "template" file to Git that knows about which lines to exclude for the purpose of rename detection (e.g. license, blank lines, indented braces, or such) Thanks, Stefan
