Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

[Stefan Beller <sbeller@google.com>]

Hi Junio,

> --------------------------------------------------
> [New Topics]

> * sb/object-store-replace (2018-04-12) 15 commits
...
>  The effort to pass the repository in-core structure throughout the
>  API continues.  This round deals with the code that implements the
>  refs/replace/ mechanism.
>
>  What's the doneness of this thing?  I didn't recall seeing any
>  response, especially ones that demonstrated the reviewer carefully
>  read and thought about the issues surrounding the code.  Not that I
>  spotted any problems in these patches myself, though.

Stolee and Brandon provided a "quick LGTM" type of review
https://public-inbox.org/git/20180409232536.GB102627@google.com/
https://public-inbox.org/git/9ddfee7e-025a-79c9-8d6b-700c65a14067@gmail.com/

I do not recall an in depth review, though Rene had some design guidance
in form of a patch, which is also the first commit of the series
https://public-inbox.org/git/38962a15-1081-bbdb-b4c4-6b46222b5f64@web.de/

My plan was to build the next series on top this week while waiting for
further review, though I wonder how much review will happen this week.
(Brandon, Jonathan Tan and Jonathan Nieder are all OOO,
Peff is on vacation, too)

I do not recall any discussion worthy design discussions left over, so
I'd lean on "cook in next for a while".

>
> --------------------------------------------------
> [Cooking]
>
> * sb/blame-color (2018-04-17) 2 commits
>  - builtin/blame: highlight recently changed lines
>  - builtin/blame: dim uninteresting metadata lines
>
>  "git blame" learns to unhighlight uninteresting metadata from the
>  originating commit on lines that are the same as the previous one,
>  and also paint lines in different colors depending on the age of
>  the commit.
>
>  The code to handle interaction between the config and command line
>  option smelled fishy.  Reviews and discussions are welcomed (not
>  just to this topic but others too ;-).

I'll look at the replies in thread there.


> * sb/submodule-move-nested (2018-03-29) 6 commits
>  - submodule: fixup nested submodules after moving the submodule
>  - submodule-config: remove submodule_from_cache
>  - submodule-config: add repository argument to submodule_from_{name, path}
>  - submodule-config: allow submodule_free to handle arbitrary repositories
>  - grep: remove "repo" arg from non-supporting funcs
>  - submodule.h: drop declaration of connect_work_tree_and_git_dir
>
>  Moving a submodule that itself has submodule in it with "git mv"
>  forgot to make necessary adjustment to the nested sub-submodules;
>  now the codepath learned to recurse into the submodules.
>
>  What's the doneness of this thing?

I considered this done a long time ago,

    "All 6 patches look good to me, thanks.
     Reviewed-by: Jonathan Tan <jonathantanmy@google.com>"

https://public-inbox.org/git/20180328161727.af10f596dffc8e01205c41dd@google.com/


Thanks,
Stefan