All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Stefan Beller <sbeller@google.com>,
	Christian Hesse <mail@eworm.de>,
	Derrick Stolee <stolee@gmail.com>,
	Brandon Williams <bmwill@google.com>
Subject: Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)
Date: Wed, 25 Apr 2018 12:35:55 +0200	[thread overview]
Message-ID: <87zi1rd14k.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <xmqqmuxr4r6n.fsf@gitster-ct.c.googlers.com>


On Wed, Apr 25 2018, Junio C. Hamano wrote:

>  THe command line completion (in contrib/) has been taught that "git

> * js/colored-push-errors (2018-04-24) 4 commits
>  - config: document the settings to colorize push errors/hints
>  - push: test to verify that push errors are colored
>  - push: colorize errors
>  - color: introduce support for colorizing stderr
>
>  Error messages from "git push" can be painted for more visibility.

This is a really good UI improvement. Just got around to looking at this
now, looks good!

> * sb/diff-color-move-more (2018-04-25) 7 commits
>  - diff.c: add --color-moved-ignore-space-delta option
>  - diff.c: decouple white space treatment from move detection algorithm
>  - diff.c: add a blocks mode for moved code detection
>  - diff.c: adjust hash function signature to match hashmap expectation
>  - diff.c: do not pass diff options as keydata to hashmap
>  - xdiff/xdiffi.c: remove unneeded function declarations
>  - xdiff/xdiff.h: remove unused flags
>
>  "git diff --color-moved" feature has further been tweaked.

I hadn't had time to look at
https://public-inbox.org/git/20180403210536.33798-1-sbeller@google.com/
before. Looks good to me, great to have the new "blocks" mode.

> * ab/simplify-perl-makefile (2018-04-19) 2 commits
>   (merged to 'next' on 2018-04-25 at 906cf21682)
>  + Makefile: mark perllibdir as a .PHONY target
>   (merged to 'next' on 2018-04-17 at 4448756934)
>  + perl: fix installing modules from contrib
>
>  Recent simplification of build procedure forgot a bit of tweak to
>  the build procedure of contrib/mw-to-git/
>
>  Will merge to 'master'.

Thanks to Christian Hesse for fixing up my mess.

> * nd/pack-objects-pack-struct (2018-04-16) 15 commits
>  - ci: exercise the whole test suite with uncommon code in pack-objects
>  - pack-objects: reorder members to shrink struct object_entry
>  - pack-objects: shrink delta_size field in struct object_entry
>  - pack-objects: shrink size field in struct object_entry
>  - pack-objects: clarify the use of object_entry::size
>  - pack-objects: don't check size when the object is bad
>  - pack-objects: shrink z_delta_size field in struct object_entry
>  - pack-objects: refer to delta objects by index instead of pointer
>  - pack-objects: move in_pack out of struct object_entry
>  - pack-objects: move in_pack_pos out of struct object_entry
>  - pack-objects: use bitfield for object_entry::depth
>  - pack-objects: use bitfield for object_entry::dfs_state
>  - pack-objects: turn type and in_pack_type to bitfields
>  - pack-objects: a bit of document about struct object_entry
>  - read-cache.c: make $GIT_TEST_SPLIT_INDEX boolean
>
>  "git pack-objects" needs to allocate tons of "struct object_entry"
>  while doing its work, and shrinking its size helps the performance
>  quite a bit.
>
>  What's the doneness of this thing?  The interdiff since previous
>  rounds looked reasonable, but I didn't see this round otherwise
>  scrutinized by reviewers.  The numbers given in the commit near the
>  tip do look impressive, though ;-)
>
> * nd/repack-keep-pack (2018-04-16) 7 commits
>  - pack-objects: show some progress when counting kept objects
>  - gc --auto: exclude base pack if not enough mem to "repack -ad"
>  - gc: handle a corner case in gc.bigPackThreshold
>  - gc: add gc.bigPackThreshold config
>  - gc: add --keep-largest-pack option
>  - repack: add --keep-pack option
>  - t7700: have closing quote of a test at the beginning of line
>
>  "git gc" in a large repository takes a lot of time as it considers
>  to repack all objects into one pack by default.  The command has
>  been taught to pretend as if the largest existing packfile is
>  marked with ".keep" so that it is left untouched while objects in
>  other packs and loose ones are repacked.
>
>  What's the doneness of this thing?  The interdiff since the earlier
>  one looked reasonable, but I didn't see this round otherwise
>  scrutinized by reviewers.

As noted in 878t9pfu4f.fsf@evledraar.gmail.com I've been running both of
these in production without issues, and in combination they really
improve performance on big repositories (especially
nd/repack-keep-pack).

I've given them a really close look and am happy to see them merged
down, although some bits of nd/pack-objects-pack-struct are way over my
head, but Peff has looked at them more closely, and seemed happy-ish
with it once the arbitrary limits present in previous rounds went away.

> * pw/add-p-select (2018-03-16) 3 commits
>  - add -p: optimize line selection for short hunks
>  - add -p: allow line selection to be inverted
>  - add -p: select individual hunk lines
>
>  "git add -p" interactive interface learned to let users choose
>  individual added/removed lines to be used in the operation, instead
>  of accepting or rejecting a whole hunk.
>
>  Expecting a reroll to reignite the discussion.
>  cf. <9895c7b7-eac4-28c1-90c6-443acd1131b7@talktalk.net>
>
>
> * ds/commit-graph (2018-04-11) 16 commits
>   (merged to 'next' on 2018-04-25 at 18af3d28d9)
>  + commit-graph: implement "--append" option
>  + commit-graph: build graph from starting commits
>  + commit-graph: read only from specific pack-indexes
>  + commit: integrate commit graph with commit parsing
>  + commit-graph: close under reachability
>  + commit-graph: add core.commitGraph setting
>  + commit-graph: implement git commit-graph read
>  + commit-graph: implement git-commit-graph write
>  + commit-graph: implement write_commit_graph()
>  + commit-graph: create git-commit-graph builtin
>  + graph: add commit graph design document
>  + commit-graph: add format document
>  + csum-file: refactor finalize_hashfile() method
>  + csum-file: rename hashclose() to finalize_hashfile()
>  + Merge branch 'jk/cached-commit-buffer' into HEAD
>  + Merge branch 'jt/binsearch-with-fanout' into HEAD
>  (this branch is used by ds/generation-numbers and ds/lazy-load-trees.)
>
>  Precompute and store information necessary for ancestry traversal
>  in a separate file to optimize graph walking.
>
>  Will merge to 'master'.

Great that this & ds/lazy-load-trees is finally landing, so we can focus
on the subsequent integration bits (git-gc, using it in --contains etc.)

> * bw/protocol-v2 (2018-03-15) 35 commits
>   (merged to 'next' on 2018-04-11 at 23ee234a2c)
>  + remote-curl: don't request v2 when pushing
>  + remote-curl: implement stateless-connect command
>  + http: eliminate "# service" line when using protocol v2
>  + http: don't always add Git-Protocol header
>  + http: allow providing extra headers for http requests
>  + remote-curl: store the protocol version the server responded with
>  + remote-curl: create copy of the service name
>  + pkt-line: add packet_buf_write_len function
>  + transport-helper: introduce stateless-connect
>  + transport-helper: refactor process_connect_service
>  + transport-helper: remove name parameter
>  + connect: don't request v2 when pushing
>  + connect: refactor git_connect to only get the protocol version once
>  + fetch-pack: support shallow requests
>  + fetch-pack: perform a fetch using v2
>  + upload-pack: introduce fetch server command
>  + push: pass ref prefixes when pushing
>  + fetch: pass ref prefixes when fetching
>  + ls-remote: pass ref prefixes when requesting a remote's refs
>  + transport: convert transport_get_remote_refs to take a list of ref prefixes
>  + transport: convert get_refs_list to take a list of ref prefixes
>  + connect: request remote refs using v2
>  + ls-refs: introduce ls-refs server command
>  + serve: introduce git-serve
>  + test-pkt-line: introduce a packet-line test helper
>  + protocol: introduce enum protocol_version value protocol_v2
>  + transport: store protocol version
>  + connect: discover protocol version outside of get_remote_heads
>  + connect: convert get_remote_heads to use struct packet_reader
>  + transport: use get_refs_via_connect to get refs
>  + upload-pack: factor out processing lines
>  + upload-pack: convert to a builtin
>  + pkt-line: add delim packet support
>  + pkt-line: allow peeking a packet line without consuming it
>  + pkt-line: introduce packet_read_with_status
>  (this branch is used by bw/server-options.)
>
>  The beginning of the next-gen transfer protocol.
>
>  Will cook in 'next'.

With a month & 10 days of no updates & this looking stable it would be
great to have it in master sooner than later to build on top of it in
the 2.18 window.

  reply	other threads:[~2018-04-25 10:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-25  8:37 What's cooking in git.git (Apr 2018, #03; Wed, 25) Junio C Hamano
2018-04-25 10:35 ` Ævar Arnfjörð Bjarmason [this message]
2018-04-25 17:43   ` Brandon Williams
2018-04-26 12:44     ` Derrick Stolee
2018-04-27  7:02       ` Johannes Schindelin
2018-04-25 12:37 ` js/rebase-recreate-merge, was " Johannes Schindelin
2018-04-25 16:21 ` Elijah Newren
2018-04-26  4:39   ` Junio C Hamano
2018-04-26  1:13 ` brian m. carlson
2018-04-26 15:26 ` Duy Nguyen
2018-04-27  7:39 ` Eric Sunshine
2018-04-30  0:03   ` 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

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

  git send-email \
    --in-reply-to=87zi1rd14k.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mail@eworm.de \
    --cc=peff@peff.net \
    --cc=sbeller@google.com \
    --cc=stolee@gmail.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.