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.
next prev parent 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).