git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: jnareb@gmail.com (Jakub Narębski)
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org,
	"Abhishek Kumar" <abhishekkumar8222@gmail.com>,
	"Derrick Stolee" <stolee@gmail.com>,
	"Taylor Blau" <me@ttaylorr.com>,
	"Jakub Narębski" <jnareb@gmail.com>
Subject: Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)
Date: Tue, 15 Sep 2020 21:05:18 +0200	[thread overview]
Message-ID: <85ft7ivp1t.fsf@LAPTOP-ACER-ASPIRE-F5.i-did-not-set--mail-host-address--so-tickle-me> (raw)
In-Reply-To: xmqq4ko6twc9.fsf@gitster.c.googlers.com

Hello,

Junio C Hamano <gitster@pobox.com> writes:

> * ss/submodule-summary-in-c (2020-08-12) 4 commits
>   (merged to 'next' on 2020-08-17 at 9bc352cb70)
>  + submodule: port submodule subcommand 'summary' from shell to C
>  + t7421: introduce a test script for verifying 'summary' output
>  + submodule: rename helper functions to avoid ambiguity
>  + submodule: remove extra line feeds between callback struct and macro
>  (this branch is used by ss/submodule-summary-in-c-fixes.)
>
>  Yet another subcommand of "git submodule" is getting rewritten in C.
>
>
> * ss/submodule-summary-in-c-fixes (2020-08-27) 3 commits
>   (merged to 'next' on 2020-09-02 at 7f959811b8)
>  + t7421: eliminate 'grep' check in t7421.4 for mingw compatibility
>  + submodule: fix style in function definition
>  + submodule: eliminate unused parameters from print_submodule_summary()
>  (this branch uses ss/submodule-summary-in-c.)
>
>  Fixups to a topic in 'next'.

Those are patches that are part of GSoC project of Shourya Shukla:
'Convert submodule to builtin'.

> * hv/ref-filter-misc (2020-08-28) 8 commits
>   (merged to 'next' on 2020-09-02 at 9a8bb84f20)
>  + ref-filter: add `sanitize` option for 'subject' atom
>  + pretty: refactor `format_sanitized_subject()`
>  + ref-filter: add `short` modifier to 'parent' atom
>  + ref-filter: add `short` modifier to 'tree' atom
>  + ref-filter: rename `objectname` related functions and fields
>  + ref-filter: modify error messages in `grab_objectname()`
>  + ref-filter: refactor `grab_objectname()`
>  + ref-filter: support different email formats
>
>  The "--format=" option to the "for-each-ref" command and friends
>  learned a few more tricks, e.g. the ":short" suffix that applies to
>  "objectname" now also can be used for "parent", "tree", etc.
>

Those are patches that are part of GSoC project of Hariom Verma:
'Unify ref-filter formats with other --pretty formats'

I'd like to point out that latest series of patches by Abhishek Kumar
which are final part of 'Implement Generation Number v2' is at what I
believe is next to final iteration:

  "[PATCH v3 00/11] [GSoC] Implement Corrected Commit Date"
  https://lore.kernel.org/git/pull.676.v3.git.1597509583.gitgitgadget@gmail.com/T/#u

It is waiting for the decision on *how to implement storing* new
generation number in the commit-graph file: should we store corrected
commit date directly as 64 bit value, or should we store corrected
commit date offset as 32 bit value with overflow handling?

Switching from 64 bits to 32 bits halves the size of the GDAT
(Generation DATa) chunk, but decreases the size of the commit-graph file
by at most 7%.  For large repository, like MS Windows with 3M commits in
2019 it would mean decreasing the size of the commit-graph file by
11.8 MiB (if I calculated it correctly).

Because corrected commit date offsets are not monotone, that is after
value that doesn't fit in 32 bits (in parent) there can be one that does
(in child).  It is extremely unlikely that in real repositories there
would be that large corrections needed, but it can happen in theory, and
therfore we need some way to handle overflow if we choose this option.
And of course we should test that overflow handling works correctly.

So there is tradeoff between complexity and commit-graph file size.

Best,
-- 
Jakub Narębski

  parent reply	other threads:[~2020-09-15 19:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-09 22:32 What's cooking in git.git (Sep 2020, #03; Wed, 9) Junio C Hamano
2020-09-09 23:07 ` Eric Sunshine
2020-09-10  4:52   ` Junio C Hamano
2020-09-15 22:48     ` Eric Sunshine
2020-09-15 22:54       ` Junio C Hamano
2020-09-15 19:05 ` Jakub Narębski [this message]
2020-09-15 19:32   ` Taylor Blau
2020-09-15 21:14   ` Junio C Hamano
2020-09-15 21:25     ` Jakub Narębski
2020-09-15 21:45       ` Junio C Hamano
2020-09-15 21:48         ` Taylor Blau
2020-09-15 22:32           ` Junio C Hamano
2020-09-15 22:02         ` Jakub Narębski

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=85ft7ivp1t.fsf@LAPTOP-ACER-ASPIRE-F5.i-did-not-set--mail-host-address--so-tickle-me \
    --to=jnareb@gmail.com \
    --cc=abhishekkumar8222@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.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.
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).