git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
From: Derrick Stolee <stolee@gmail.com>
To: Ævar Arnfjörð Bjarmason <avarab@gmail.com>,
	Junio C Hamano <gitster@pobox.com>
Cc: Git List <git@vger.kernel.org>, Jeff King <peff@peff.net>,
	Jakub Narębski <jnareb@gmail.com>,
	Derrick Stolee <dstolee@microsoft.com>
Subject: Re: [RFC] Generation Number v2
Date: Wed, 31 Oct 2018 09:04:12 -0400
Message-ID: <6902dbff-d9f6-e897-2c20-d0cb47a50795@gmail.com> (raw)
In-Reply-To: <875zxil1if.fsf@evledraar.gmail.com>

On 10/31/2018 8:54 AM, Ævar Arnfjörð Bjarmason wrote:
> On Tue, Oct 30 2018, Junio C Hamano wrote:
>
>> Derrick Stolee <stolee@gmail.com> writes:
>>> In contrast, maximum generation numbers and corrected commit
>>> dates both performed quite well. They are frequently the top
>>> two performing indexes, and rarely significantly different.
>>>
>>> The trade-off here now seems to be: which _property_ is more important,
>>> locally-computable or backwards-compatible?
>> Nice summary.
>>
>> As I already said, I personally do not think being compatible with
>> currently deployed clients is important at all (primarily because I
>> still consider the whole thing experimental), and there is a clear
>> way forward once we correct the mistake of not having a version
>> number in the file format that tells the updated clients to ignore
>> the generation numbers.  For longer term viability, we should pick
>> something that is immutable, reproducible, computable with minimum
>> input---all of which would lead to being incrementally computable, I
>> would think.
> I think it depends on what we mean by backwards compatibility. None of
> our docs are saying this is experimental right now, just that it's
> opt-in like so many other git-config(1) options.
>
> So if we mean breaking backwards compatibility in that we'll write a new
> file or clobber the existing one with a version older clients can't use
> as an optimization, fine.
>
> But it would be bad to produce a hard error on older clients, but
> avoiding that seems as easy as just creating a "commit-graph2" file in
> .git/objects/info/.

Well, we have a 1-byte version number following the "CGPH" header in
the commit-graph file, and clients will ignore the commit-graph file
if that number is not "1". My hope for backwards-compatibility was
to avoid incrementing this value and instead use the unused 8th byte.

However, it appears that we are destined to increment that version
number, anyway. Here is my list for what needs to be in the next
version of the commit-graph file format:

1. A four-byte hash version.

2. File incrementality (split commit-graph).

3. Reachability Index versioning

Most of these changes will happen in the file header. The chunks
themselves don't need to change, but some chunks may be added that
only make sense in v2 commit-graphs.

Thanks,
-Stolee

  reply index

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-29 16:55 Derrick Stolee
2018-10-29 19:22 ` Stefan Beller
2018-10-29 20:06   ` Derrick Stolee
2018-11-01 20:06   ` Jakub Narebski
2018-11-02  9:30     ` Jakub Narebski
2018-11-03 17:27       ` Jakub Narebski
2018-10-29 20:25 ` Derrick Stolee
2018-11-01 22:13   ` Jakub Narebski
2018-10-30  3:59 ` Junio C Hamano
2018-10-31 12:30   ` Derrick Stolee
2018-11-02 13:33     ` Jakub Narebski
2018-10-31 12:54   ` Ævar Arnfjörð Bjarmason
2018-10-31 13:04     ` Derrick Stolee [this message]
2018-11-02 17:44       ` Jakub Narebski
2018-11-01 12:27 ` Jakub Narebski
2018-11-01 13:29   ` Derrick Stolee
2018-11-03 12:33     ` Jakub Narebski

Reply instructions:

You may reply publically 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=6902dbff-d9f6-e897-2c20-d0cb47a50795@gmail.com \
    --to=stolee@gmail.com \
    --cc=avarab@gmail.com \
    --cc=dstolee@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jnareb@gmail.com \
    --cc=peff@peff.net \
    /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

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Example config snippet for mirrors

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git