From: Josh Steadmon <steadmon@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
git@vger.kernel.org, "Denton Liu" <liu.denton@gmail.com>,
"Jeff Hostetler" <git@jeffhostetler.com>
Subject: Re: What's cooking in git.git (Apr 2019, #01; Thu, 4)
Date: Mon, 8 Apr 2019 14:18:50 -0700 [thread overview]
Message-ID: <20190408211850.GJ60888@google.com> (raw)
In-Reply-To: <xmqqa7h1aznl.fsf@gitster-ct.c.googlers.com>
On 2019.04.08 13:28, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
> > unique (AFAICT "actually unique" in practice) in the parallel in-flight
> > jh/trace2-sid-fix
> > (https://public-inbox.org/git/4352952677a11776a18ec9b6862cf358307cfafd.1553879063.git.gitgitgadget@gmail.com/)
> >
> > I think it's fine to merge js/trace2-to-directory down as it is, but do
> > you/Josh think that retry logic needs to stay with that sort of SID?
>
> I do not speak for Josh, but I think the only two logical choices
> are to open with (O_CREAT|O_EXCL) and
>
> (1) fallback with .%d suffix, making it clear that we are not
> willing to lose log files even when SID generation is botched; or
>
> (2) die/BUG when it fails, making it clear that we do rely on the
> guanateed uniqueness of SID.
>
> A distant third may be to warn when open with O_CREAT|O_EXCL fails,
> but I am not sure what its value would be to do so---especially if
> we trust in the "actually unique in practice". Between (1) and (2),
> I have a slight preference to (1) over (2), as that is much easier
> to explain.
>
> Those who want to have a "fixed width" thing could just ignore the
> ones with suffix---as long as the "actually unique in practice"
> claim holds, doing so will not lose any non-negligible amount of
> information anyway.
I prefer (1) as well, although I would be happy to re-write this if the
list consensus goes the other way.
prev parent reply other threads:[~2019-04-08 21:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-04 10:28 What's cooking in git.git (Apr 2019, #01; Thu, 4) Junio C Hamano
2019-04-04 11:08 ` Duy Nguyen
2019-04-04 21:29 ` Junio C Hamano
2019-04-06 20:28 ` Ævar Arnfjörð Bjarmason
2019-04-08 4:14 ` Junio C Hamano
2019-04-09 10:26 ` [PATCH] Introduce "precious" file concept Nguyễn Thái Ngọc Duy
2019-04-09 11:31 ` Junio C Hamano
2019-04-10 9:36 ` Duy Nguyen
2019-04-12 1:28 ` Junio C Hamano
2019-04-09 17:44 ` Eric Sunshine
2019-04-12 21:54 ` Ævar Arnfjörð Bjarmason
2019-04-13 10:19 ` Duy Nguyen
2019-04-05 1:05 ` What's cooking in git.git (Apr 2019, #01; Thu, 4) Todd Zullinger
2019-04-05 5:41 ` Junio C Hamano
2019-04-06 19:28 ` Ævar Arnfjörð Bjarmason
2019-04-08 4:18 ` Junio C Hamano
2019-04-06 19:57 ` Ævar Arnfjörð Bjarmason
2019-04-08 4:28 ` Junio C Hamano
2019-04-08 21:18 ` Josh Steadmon [this message]
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=20190408211850.GJ60888@google.com \
--to=steadmon@google.com \
--cc=avarab@gmail.com \
--cc=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=liu.denton@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.