list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: (Jakub Narębski)
Cc:, Abhishek Kumar <>,
	Derrick Stolee <>, Taylor Blau <>
Subject: Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)
Date: Tue, 15 Sep 2020 14:14:18 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <85ft7ivp1t.fsf@LAPTOP-ACER-ASPIRE-F5.i-did-not-set--mail-host-address--so-tickle-me> ("Jakub =?utf-8?Q?Nar=C4=99bski=22's?= message of "Tue, 15 Sep 2020 21:05:18 +0200") (Jakub Narębski) writes:

> Those are patches that are part of GSoC project of Shourya Shukla:
> 'Convert submodule to builtin'.
> ...
> Those are patches that are part of GSoC project of Hariom Verma:
> 'Unify ref-filter formats with other --pretty formats'

Yes and yes.  What is your intention for highlighting that these two
are GSoC originated projects, by the way?  

These entries in the What's cooking report will eventually be part
of the Release Notes, it is tempting to mention it there for
publicity of the GSoC program (and I happen to work for OSPO that
runs the program).

But at the same time, it becomes part of the published history
(i.e. commit log for the merge commits) and over there, I am not
sure if we want to mention GSoC---who the changes came from and in
what context is much less important than what the actual changes are
while reading the history of the project, trying to understand the
current state of the code [*1*].

> 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:

Yup, I've been watching from the sideline and appreciate that you've
given the author quite a lot of help to make the series into a good

> 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.

My gut feeling is that overflow handling needs there whether the
field is 32-bit or 64-bit.



*1* Unless you want to have more cues to notice commits by less
    experienced contributors and want to focus more carefully while
    bisecting the history or something like that, that is.

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

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-09 22:32 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
2020-09-15 19:32   ` Taylor Blau
2020-09-15 21:14   ` Junio C Hamano [this message]
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:

  List information:

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

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: What'\''s cooking in git.git (Sep 2020, #03; Wed, 9)' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

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).