What's cooking in git.git (Jun 2018, #07; Thu, 28)

13 messages, 9 authors, 2018-07-09 · open the first message on its own page

What's cooking in git.git (Jun 2018, #07; Thu, 28)

From: Junio C Hamano <hidden>
Date: 2018-06-28 21:40:39

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.

The tip of 'next' has been rewound and it currently has only 4
topics.  Quite a many topics are cooking in 'pu' and need to be
sifted into good bins (for 'next') and the remainder.  Help is
appreciated in that area ;-)

You can find the changes described here in the integration branches
of the repositories listed at

    http://git-blame.blogspot.com/p/git-public-repositories.html

--------------------------------------------------
[Graduated to "master"]

* ab/refspec-init-fix (2018-06-11) 3 commits
  (merged to 'next' on 2018-06-13 at 91d71d8435)
 + refspec: initalize `refspec_item` in `valid_fetch_refspec()`
 + refspec: add back a refspec_item_init() function
 + refspec: s/refspec_item_init/&_or_die/g

 Make refspec parsing codepath more robust.


* as/safecrlf-quiet-fix (2018-06-11) 1 commit
  (merged to 'next' on 2018-06-13 at b163674843)
 + config.c: fix regression for core.safecrlf false

 Fix for 2.17-era regression around `core.safecrlf`.


* jc/clean-after-sanity-tests (2018-06-15) 1 commit
  (merged to 'next' on 2018-06-22 at 2df77b8af9)
 + tests: clean after SANITY tests

 test cleanup.

792 more lines

Re: What's cooking in git.git (Jun 2018, #07; Thu, 28)

From: Stefan Beller <hidden>
Date: 2018-06-28 22:43:13

On Thu, Jun 28, 2018 at 2:40 PM Junio C Hamano [off-list ref] wrote:
The tip of 'next' has been rewound and it currently has only 4
topics.  Quite a many topics are cooking in 'pu' and need to be
sifted into good bins (for 'next') and the remainder.  Help is
appreciated in that area ;-)
Which branches are needing review most? Or should I start
commenting on random stuff? ;-)
* bw/ref-in-want (2018-06-28) 8 commits
 - fetch-pack: implement ref-in-want
 - fetch-pack: put shallow info in output parameter
 - fetch: refactor to make function args narrower
 - fetch: refactor fetch_refs into two functions
 - fetch: refactor the population of peer ref OIDs
 - upload-pack: test negotiation with changing repository
 - upload-pack: implement ref-in-want
 - test-pkt-line: add unpack-sideband subcommand

 Protocol v2 has been updated to allow slightly out-of-sync set of
 servers to work together to serve a single client, which would be
 useful with load-balanced servers that talk smart HTTP transport.
I think another selling point, which should be emphasized more is
the ease of ACL checking on the server side.
Even when the read permissions are per repository (e.g. githubs
model AFAICT), the serving side still has to do a lookup "Can
a wanted sha1 be reached from all refs?", which now can be
optimized away ("Can I access the master branch?") and it
is cheaper to run the server.
Specifically if read permissions are per ref (Gerrits model), I'd
expect some CPU savings on the serving side.
* jt/remove-pack-bitmap-global (2018-06-21) 2 commits
 - pack-bitmap: add free function
 - pack-bitmap: remove bitmap_git global variable

 The effort to move globals to per-repository in-core structure
 continues.
This is mostly done, though Peff seems to expect a reroll with
clarification on how the series is structured?
https://public-inbox.org/git/20180611211033.GB26235@sigill.intra.peff.net/
* sb/submodule-move-head-error-msg (2018-06-25) 1 commit
 - submodule.c: report the submodule that an error occurs in

 Needs a reroll.
 cf. [off-list ref]
https://public-inbox.org/git/xmqqmuviq2n7.fsf@gitster-ct.c.googlers.com/

suggests that you applied that change and a reroll would not be needed.

* ds/multi-pack-index (2018-06-25) 24 commits
 - midx: clear midx on repack
 - packfile: skip loading index if in multi-pack-index
 - midx: prevent duplicate packfile loads
 - midx: use midx in approximate_object_count
 - midx: use existing midx when writing new one
 - midx: use midx in abbreviation calculations
 - midx: read objects from multi-pack-index
 - midx: prepare midxed_git struct
 - config: create core.multiPackIndex setting
 - midx: write object offsets
 - midx: write object id fanout chunk
 - midx: write object ids in a chunk
 - midx: sort and deduplicate objects from packfiles
 - midx: read pack names into array
 - multi-pack-index: write pack names in chunk
 - multi-pack-index: read packfile list
 - packfile: generalize pack directory list
 - multi-pack-index: expand test data
 - multi-pack-index: load into memory
 - midx: write header information to lockfile
 - multi-pack-index: add 'write' verb
 - multi-pack-index: add builtin
 - multi-pack-index: add format details
 - multi-pack-index: add design document

 When there are too many packfiles in a repository (which is not
 recommended), looking up an object in these would require
 consulting many pack .idx files; a new mechanism to have a single
 file that consolidates all of these .idx files is introduced.


* nd/use-the-index-compat-less (2018-06-25) 13 commits
 - wt-status.c: stop using index compat macros
 - sha1-name.c: stop using index compat macros
 - sequencer.c: stop using index compat macros
 - revision.c: stop using index compat macros
 - rerere.c: stop using index compat macros
 - merge.c: stop using index compat macros

15 more quoted lines

As someone who also does lots of refactoring lately, I am excited
to see the code health moving in the right direction.

It is easy to quantify how often we are bitten by code churn
(that you call useless here); and very hard to quantify bugs
introduced or features not written/upstreamed due to clunky
API (as we don't see those or do not attribute a bug to a bad API).
So we are naturally biased towards seeing code churn
as bad, as the signals favor one over the other.
* jt/fetch-pack-negotiator (2018-06-15) 7 commits
 - fetch-pack: introduce negotiator API
 - fetch-pack: move common check and marking together
 - fetch-pack: make negotiation-related vars local
 - fetch-pack: use ref adv. to prune "have" sent
 - fetch-pack: directly end negotiation if ACK ready
 - fetch-pack: clear marks before re-marking
 - fetch-pack: split up everything_local()
 (this branch is used by jt/fetch-nego-tip.)

 Code restructuring and a small fix to transport protocol v2 during
 fetching.

 Is this ready for 'next'?
That is a good topic to review for me, I'll jump on it.
* ds/commit-graph-fsck (2018-06-27) 22 commits
[...]
 "git fsck" learns to make sure the optional commit-graph file is in
 a sane state.

 Is this ready for 'next'?
I hope so, as I plan to reroll the next object store series based
on it. I'll also review that.
* jm/cache-entry-from-mem-pool (2018-06-28) 8 commits
 - block alloc: add validations around cache_entry lifecyle
 - block alloc: allocate cache entries from mem-pool
 - mem-pool: fill out functionality
 - mem-pool: add life cycle management functions
 - mem-pool: only search head block for available space
 - block alloc: add lifecycle APIs for cache_entry structs
 - read-cache: make_cache_entry should take object_id struct
 - read-cache: teach refresh_cache_entry() to take istate

 For a large tree, the index needs to hold many cache entries
 allocated on heap.  These cache entries are now allocated out of a
 dedicated memory pool to amortize malloc(3) overhead.
This is also on my review todo list, still.
* sb/diff-color-move-more (2018-06-25) 11 commits
 - diff: fix a sparse 'dubious one-bit signed bitfield' error
 - SQUASH??? t/4015 GETTEXT_POISON emergency fix
 - SQUASH????? Documentation breakage emergency fix
[...]
 "git diff --color-moved" feature has further been tweaked.

 Needs to be cleaned-up with various fix-up bits applied inline.
I'll resend with those squashes and another (test-)fix SZEDER
mentioned soon.

Thanks,
Stefan

ag/rebase-i-append-todo-help, was Re: What's cooking in git.git (Jun 2018, #07; Thu, 28)

From: Alban Gruin <hidden>
Date: 2018-06-29 11:10:44

Hi Junio,

Le 28/06/2018 à 23:40, Junio C Hamano a écrit :
* ag/rebase-i-append-todo-help (2018-06-14) 2 commits
 - rebase--interactive: rewrite append_todo_help() in C
 - Merge branch 'ag/rebase-p' into ag/rebase-i-append-todo-help
 (this branch is used by ag/rebase-i-rewrite-todo.)

 Stepwise rewriting of the machinery of "rebase -i" into C continues.

 Needs a reroll.
 cf. [off-list ref]
As I moved append_todo_help() to `rebase-interactive.c`, it should be
because I did not changed `msg = _(…)` to `msg = N_(…)`.

It was pointed out on IRC that it was not necessary, after all[0].
Basically, N_() is needed for static variables, not for "dynamic"
variables like `msg` in append_todo_help().

[0] http://colabti.org/irclogger/irclogger_log/git-devel?date=2018-06-26#l44

Cheers,
Alban

Re: What's cooking in git.git (Jun 2018, #07; Thu, 28)

From: Derrick Stolee <hidden>
Date: 2018-06-29 13:55:59

On 6/28/2018 6:42 PM, Stefan Beller wrote:
On Thu, Jun 28, 2018 at 2:40 PM Junio C Hamano [off-list ref] wrote:
quoted
* ds/commit-graph-fsck (2018-06-27) 22 commits
[...]
quoted
  "git fsck" learns to make sure the optional commit-graph file is in
  a sane state.

  Is this ready for 'next'?
I hope so, as I plan to reroll the next object store series based
on it. I'll also review that.
I think the series is ready. The only new feedback in a while is your style comments on "commit-graph: add '--reachable' option", which can hopefully be squashed in. I'm also open to sending a new series on top for new feedback.

Thanks,

-Stolee

Re: What's cooking in git.git (Jun 2018, #07; Thu, 28)

From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2018-06-29 21:04:48

On Thu, Jun 28 2018, Junio C Hamano wrote:
The tip of 'next' has been rewound and it currently has only 4
topics.  Quite a many topics are cooking in 'pu' and need to be
sifted into good bins (for 'next') and the remainder.  Help is
appreciated in that area ;-)
Per my
https://public-inbox.org/git/CACBZZX4yG5h5kk4NFQz_NzAweMa+Nh3H-39OHtcH4XWsA6FGpg@mail.gmail.com/
(seems to not have been seen) I'd like to suggest that:

[...]
* ab/fetch-tags-noclobber (2018-05-16) 9 commits
This be ejected for now.

[...]
* ab/checkout-default-remote (2018-06-11) 8 commits
And this be merged down to "next".

as/safecrlf-quiet-fix, was Re: What's cooking in git.git (Jun 2018, #07; Thu, 28)

From: Johannes Schindelin <hidden>
Date: 2018-07-03 11:45:00

Hi Junio,

On Thu, 28 Jun 2018, Junio C Hamano wrote:
* as/safecrlf-quiet-fix (2018-06-11) 1 commit
  (merged to 'next' on 2018-06-13 at b163674843)
 + config.c: fix regression for core.safecrlf false

 Fix for 2.17-era regression around `core.safecrlf`.
Is this `maint` material?

Ciao,
Dscho

jh/partial-clone, was Re: What's cooking in git.git (Jun 2018, #07; Thu, 28)

From: Johannes Schindelin <hidden>
Date: 2018-07-03 11:47:18

Hi Junio,

On Thu, 28 Jun 2018, Junio C Hamano wrote:
* jh/partial-clone (2018-06-12) 1 commit
  (merged to 'next' on 2018-06-13 at 818f864b0c)
 + list-objects: check if filter is NULL before using

 The recent addition of "partial clone" experimental feature kicked
 in when it shouldn't, namely, when there is no partial-clone filter
 defined even if extensions.partialclone is set.
Is this `maint` material?

Ciao,
Dscho

as/sequencer-customizable-comment-char, was Re: What's cooking in git.git (Jun 2018, #07; Thu, 28)

From: Johannes Schindelin <hidden>
Date: 2018-07-03 11:54:46

Hi Junio & Aaron,

On Thu, 28 Jun 2018, Junio C Hamano wrote:
* as/sequencer-customizable-comment-char (2018-06-28) 1 commit
 - sequencer: use configured comment character

 Honor core.commentchar when preparing the list of commits to replay
 in "rebase -i".
As per
https://public-inbox.org/git/nycvar.QRO.7.76.6.1806291607501.74@tvgsbejvaqbjf.bet/
I am inclined to ask for a "v2" (i.e. second iteration of the patch, see
e.g.
https://github.com/git-for-windows/git/blob/master/CONTRIBUTING.md#submit-the-patch
where it talks about submitting an "nth version") that adds an explanation
to the commit message why the "auto" value is handled correctly by this
patch, as this is not really obvious from reading the diff alone.

After that change, I think this is ready for `next`.

Ciao,
Dscho

ag/rebase-i-rewrite-todo, was Re: What's cooking in git.git (Jun 2018, #07; Thu, 28)

From: Johannes Schindelin <hidden>
Date: 2018-07-03 12:52:56

Hi Junio,

On Thu, 28 Jun 2018, Junio C Hamano wrote:
* ag/rebase-i-rewrite-todo (2018-06-15) 3 commits
 - rebase--interactive: rewrite the edit-todo functionality in C
 - editor: add a function to launch the sequence editor
 - Merge branch 'bc/t3430-fixup' into ag/rebase-i-rewrite-todo
 (this branch uses ag/rebase-i-append-todo-help.)

 Stepwise rewriting of the machinery of "rebase -i" into C continues.
Alban abided by your wish and smooshed those patch series into one honking
big one, to grow even further with his ongoing work. I have to admit that
I am not enthusiastic about this, as it will make it even harder to
squeeze in the time for me to review those patches.

The latest iteration of this is here:
https://public-inbox.org/git/20180702105717.26386-5-alban.gruin@gmail.com/T/#r8eea71077745d6f2c839acb6200bb8b2bea579d3

I would *strongly* encourage you to allow Alban to go back to the small,
incremental patch series he sent before, because it will make it
*substantially* easier to not only review, but also develop, and for you
to merge.

In this case, for example, the two patches in
https://public-inbox.org/git/20180702105717.26386-4-alban.gruin@gmail.com/
and
https://public-inbox.org/git/20180702105717.26386-5-alban.gruin@gmail.com/
are ready to go into `next`, like, right now.

Yet because they are now embedded in a larger patch series, they will have
to be re-rolled over and over again until *all* of
`git-rebase--interactive.sh` is rewritten in C?  That's really wasteful of
reviewers' time.

Ciao,
Dscho

js/branch-diff, was Re: What's cooking in git.git (Jun 2018, #07; Thu, 28)

From: Johannes Schindelin <hidden>
Date: 2018-07-03 13:06:19

Hi Junio,

On Thu, 28 Jun 2018, Junio C Hamano wrote:
* js/branch-diff (2018-05-16) 19 commits
 - fixup! Add a function to solve least-cost assignment problems
 - completion: support branch-diff
 - branch-diff: add a man page
 - branch-diff --dual-color: work around bogus white-space warning
 - branch-diff: offer to dual-color the diffs
 - diff: add an internal option to dual-color diffs of diffs
 - color: provide inverted colors, too
 - branch-diff: use color for the commit pairs
 - branch-diff: add tests
 - branch-diff: do not show "function names" in hunk headers
 - branch-diff: adjust the output of the commit pairs
 - branch-diff: suppress the diff headers
 - branch-diff: indent the diffs just like tbdiff
 - branch-diff: right-trim commit messages
 - branch-diff: also show the diff between patches
 - branch-diff: improve the order of the shown commits
 - branch-diff: first rudimentary implementation
 - Add a new builtin: branch-diff
 - Add a function to solve least-cost assignment problems

 "git tbdiff" that lets us compare individual patches in two
 iterations of a topic has been rewritten and made into a built-in
 command.

 Expecting a reroll.
 cf. [off-list ref]
I rolled it around so hard that it got dizzy.

(Yes, I just made fun of this Git speak "to re-roll".)

Seriously again, I sent a new iteration:

	https://public-inbox.org/git/pull.1.v3.git.gitgitgadget@gmail.com/

Ciao,
Dscho

Re: What's cooking in git.git (Jun 2018, #07; Thu, 28)

From: Elijah Newren <hidden>
Date: 2018-07-03 18:31:04

Hi Derrick,

On Thu, Jun 28, 2018 at 2:40 PM, Junio C Hamano [off-list ref] wrote:
* ds/multi-pack-index (2018-06-25) 24 commits
 - midx: clear midx on repack
 - packfile: skip loading index if in multi-pack-index
 - midx: prevent duplicate packfile loads
 - midx: use midx in approximate_object_count
 - midx: use existing midx when writing new one
 - midx: use midx in abbreviation calculations
 - midx: read objects from multi-pack-index
 - midx: prepare midxed_git struct
 - config: create core.multiPackIndex setting
 - midx: write object offsets
 - midx: write object id fanout chunk
 - midx: write object ids in a chunk
 - midx: sort and deduplicate objects from packfiles
 - midx: read pack names into array
 - multi-pack-index: write pack names in chunk
 - multi-pack-index: read packfile list
 - packfile: generalize pack directory list
 - multi-pack-index: expand test data
 - multi-pack-index: load into memory
 - midx: write header information to lockfile
 - multi-pack-index: add 'write' verb
 - multi-pack-index: add builtin
 - multi-pack-index: add format details
 - multi-pack-index: add design document

 When there are too many packfiles in a repository (which is not
 recommended), looking up an object in these would require
 consulting many pack .idx files; a new mechanism to have a single
 file that consolidates all of these .idx files is introduced.
pu fails to build for me (with the standard 'make DEVELOPER=1 ...'),
and it appears to come from this series:

midx.c:567:15: error: ‘write_midx_pack_lookup’ defined but not used
[-Werror=unused-function]
 static size_t write_midx_pack_lookup(struct hashfile *f,

It looks like the use of this function was removed in v2 of your
series, but the function itself was left behind?  Could you take a
look?

Thanks,
Elijah

Re: What's cooking in git.git (Jun 2018, #07; Thu, 28)

From: Eric Sunshine <hidden>
Date: 2018-07-03 18:33:24

On Tue, Jul 3, 2018 at 2:31 PM Elijah Newren [off-list ref] wrote:
On Thu, Jun 28, 2018 at 2:40 PM, Junio C Hamano [off-list ref] wrote:
quoted
* ds/multi-pack-index (2018-06-25) 24 commits
pu fails to build for me (with the standard 'make DEVELOPER=1 ...'),
and it appears to come from this series:

midx.c:567:15: error: ‘write_midx_pack_lookup’ defined but not used
[-Werror=unused-function]
 static size_t write_midx_pack_lookup(struct hashfile *f,

It looks like the use of this function was removed in v2 of your
series, but the function itself was left behind?  Could you take a
look?
Also reported here [1].

[1]: https://public-inbox.org/git/CAPig+cRWwTAFRJOwQOi4USk5UZke=2sz_JVDh3+XRKCcBGD5ow@mail.gmail.com/

Re: What's cooking in git.git (Jun 2018, #07; Thu, 28)

From: Jonathan Tan <hidden>
Date: 2018-07-09 17:31:38

* jt/fetch-pack-negotiator (2018-06-15) 7 commits
 - fetch-pack: introduce negotiator API
 - fetch-pack: move common check and marking together
 - fetch-pack: make negotiation-related vars local
 - fetch-pack: use ref adv. to prune "have" sent
 - fetch-pack: directly end negotiation if ACK ready
 - fetch-pack: clear marks before re-marking
 - fetch-pack: split up everything_local()
 (this branch is used by jt/fetch-nego-tip.)

 Code restructuring and a small fix to transport protocol v2 during
 fetching.

 Is this ready for 'next'?
Sorry for the late reply - I think that this is ready for "next". I have
addressed all the comments that you, Jonathan Nieder and Brandon
Williams have given, and Brandon has given his OK [1].

[1] https://public-inbox.org/git/20180625182434.GE19910@google.com/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help