git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stefan Beller <sbeller@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git <git@vger.kernel.org>
Subject: Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)
Date: Wed, 25 Jul 2018 15:56:17 -0700	[thread overview]
Message-ID: <CAGZ79kbO1KOfDgjT5duEd49MZ=EaYLtTDeg2efVO5kkO9QFx7g@mail.gmail.com> (raw)
In-Reply-To: <xmqqd0vbt14e.fsf@gitster-ct.c.googlers.com>

On Wed, Jul 25, 2018 at 3:13 PM Junio C Hamano <gitster@pobox.com> 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.

  reply	other threads:[~2018-07-25 22:56 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-25 22:13 What's cooking in git.git (Jul 2018, #03; Wed, 25) Junio C Hamano
2018-07-25 22:56 ` Stefan Beller [this message]
2018-07-25 23:43   ` Junio C Hamano
2018-07-26  4:14     ` Junio C Hamano
2018-07-26 16:56     ` Junio C Hamano
2018-07-25 23:47   ` Junio C Hamano
2018-07-25 23:48   ` Junio C Hamano
2018-07-26  4:15     ` Junio C Hamano
2018-07-26  6:07 ` Оля Тележная
2018-07-26 16:57   ` Junio C Hamano
2018-08-02 12:41     ` Christian Couder
2018-08-02 18:40       ` Junio C Hamano
2018-07-26  7:24 ` Jeff King
2018-07-26 16:57   ` Junio C Hamano
2018-07-26 20:46     ` Jeff King
2018-07-27 14:28 ` Ævar Arnfjörð Bjarmason
2018-07-27 17:28   ` Junio C Hamano
2018-07-30 13:16     ` range-diff, was " Johannes Schindelin
2018-07-30 15:41       ` Junio C Hamano
2018-08-01 16:01         ` Johannes Schindelin
2018-08-01 19:11           ` Junio C Hamano
2018-08-01 20:44 ` ds/reachable (was Re: What's cooking in git.git (Jul 2018, #03; Wed, 25)) Derrick Stolee
2018-08-01 21:55   ` Junio C Hamano
2018-08-01 20:53 ` ds/multi-pack-index " Derrick Stolee
2018-08-01 22:13   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGZ79kbO1KOfDgjT5duEd49MZ=EaYLtTDeg2efVO5kkO9QFx7g@mail.gmail.com' \
    --to=sbeller@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).