Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 25, 2018 at 3:13 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Here are the topics that have been cooking.  Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'.  The ones marked with '.' do not appear in any of
> the integration branches, but I am still holding onto them.
>
> Many topics have moved to 'master' and 'next' from 'next' to 'pu'
> respectively.
>
> You can find the changes described here in the integration branches
> of the repositories listed at

(using an alias to fetch all using protocol v2)
Fetching o
>From https://github.com/gitster/git
 - [deleted]                 (none)     -> origin/ab/fetch-tags-noclobber
 - [deleted]                 (none)     -> origin/nd/use-the-index-compat-less
 - [deleted]                 (none)     -> origin/sb/diff-color-move
remote: Counting objects: 830, done.
remote: Compressing objects: 100% (379/379), done.
remote: Total 830 (delta 404), reused 777 (delta 404), pack-reused 47
Receiving objects: 100% (830/830), 470.12 KiB | 9.04 MiB/s, done.
Resolving deltas: 100% (404/404), completed with 58 local objects.
fatal: Couldn't find remote ref refs/notes/amlog
error: Could not fetch o
...
(goes and pastes this into the email, what if I try again?)

$ git -c protocol.version=0 fetch --all
Fetching o
>From https://github.com/gitster/git
 * [new branch]              ab/newhash-is-sha256       ->
origin/ab/newhash-is-sha256
 + 6da893ab657...729b3925ed9 bb/make-developer-pedantic ->
origin/bb/make-developer-pedantic  (forced update)
 * [new branch]              bb/redecl-enum-fix         ->
origin/bb/redecl-enum-fix
 * [new branch]              es/diff-color-move-fix     ->
origin/es/diff-color-move-fix
 + 165e30f8529...d63a0b5e393 es/format-patch-rangediff  ->
origin/es/format-patch-rangediff  (forced update)
 + 1ac17a46fab...bb4a134ae84 jch                        -> origin/jch
(forced update)
 * [new branch]              jh/structured-logging      ->
origin/jh/structured-logging
 + 816325b2109...c255a588bcd js/range-diff              ->
origin/js/range-diff  (forced update)
   b7bd9486b05..ffc6fa0e396  master                     -> origin/master
   5c9ce644c39..a71716f1ade  next                       -> origin/next
 + 8a589a4fc91...838143aa5c0 pu                         -> origin/pu
(forced update)
 + 0041456f5f1...16d09ff91a2 refs/notes/amlog           ->
refs/notes/amlog  (forced update)
Fetching googlesource
...


> * jh/structured-logging (2018-07-25) 25 commits
[...]
>  - structured-logging: design document
>  (this branch uses jh/json-writer.)
>
>  X-Gah.

I am not sure what to make of this comment?
Does it need review or is the design/intent to be
discussed?


> [Cooking]
[...]
> * sb/submodule-update-in-c (2018-07-18) 6 commits
>  - submodule--helper: introduce new update-module-mode helper
>  - builtin/submodule--helper: factor out method to update a single submodule
>  - builtin/submodule--helper: store update_clone information in a struct
>  - builtin/submodule--helper: factor out submodule updating
>  - git-submodule.sh: rename unused variables
>  - git-submodule.sh: align error reporting for update mode to use path
>
>  "git submodule update" is getting rewritten piece-by-piece into C.
>
>  It seems to pass its own self-tests standalone, but seems to break
>  horribly when merged to 'pu'.

I need to redo this, please eject from pu if that is easier for us.

> * ag/rebase-i-in-c (2018-07-10) 13 commits
[...]
>
>  Piecemeal rewrite of the remaining "rebase -i" machinery in C.
>
>  A reroll (which is rumored to be quite good) exists, but hasn't
>  been picked up yet.

Forgot to state so on either the mailing list (or Github or IRC),
but I read the tip of the reroll and I think it is good.

> * sb/object-store-lookup (2018-06-29) 33 commits
[...]
>
>  Will merge to 'master'.

Finally. Hooray! I am currently writing its successor in a
"less confrontational (but needing more work)"-kind-of way,
which converts the ref store to take repository objects.

Given this series (and how it was done/reviewed and yet
caused so much trouble), I'd like to spark a discussion on
how the community wants to see large scale refactorings
and eventually document it.

> * js/range-diff (2018-07-25) 21 commits
[...]
>  (this branch is used by es/format-patch-rangediff.)
>
>  "git tbdiff" that lets us compare individual patches in two
>  iterations of a topic has been rewritten and made into a built-in
>  command.
>
>  Undecided.
>
>  Many "The feature is useful" comments without much real review; we
>  know the feature is great as this mimicks tbdiff already so that is
>  not news.

It has also seen reviews regarding its non-coloring side in previous rounds,
which I think is mature by now. I suggested to submit the range-diff
without coloring on IRC, but it was not quite well received as colors
were seen as "the main benefit of range-diff" by DScho.
(http://colabti.org/irclogger/irclogger_log/git-devel?date=2018-07-25#l72)

>  I've squashed an obvious documentation fix in before rebasing the
>  other topic that depends on it.  I _think_ we would probably be
>  better off to _disable_ whitespace-error coloring altogether when
>  showing diff-of-diff, and get rid of the workaround that only is
>  applicable to the context lines of the outer diff (unless we first
>  define how whitespace errors in diff-of-diff should be colored and
>  implement it correctly, that is, but after seeing these two
>  attempts, it seems that is harder than it is worth).

I think the current coloring is good enough to ship, but it still has
errors around corners, for example introduction of new files,
having lines in the inner diff as:

     diff --git a/Makefile b/Makefile
     --- a/Makefile
     +++ b/Makefile

will be colored white/red/green (in that order), but in the outer diff
these are all "context", but as these specific context lines happen
to start with +/- we color them.
If we want to be perfect, we rather need to parse&understand
the inner diff on a more detailed level, but I would argue to leave
that to a later stage for another volunteer to step in and cleanup.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux