From: Junio C Hamano <gitster@pobox.com>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
git@vger.kernel.org, "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Eric Sunshine" <sunshine@sunshineco.com>
Subject: Re: [PATCH v4] gc: save log from daemonized gc --auto and print it next time
Date: Wed, 16 Sep 2015 09:00:18 -0700 [thread overview]
Message-ID: <xmqqmvwms6b1.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <55F93646.9050709@alum.mit.edu> (Michael Haggerty's message of "Wed, 16 Sep 2015 11:28:38 +0200")
Michael Haggerty <mhagger@alum.mit.edu> writes:
> I'm not sure what behavior you want. At one point you say "puts the file
> to a final place if it is non-empty" but later you say "leave it if
> non-empty". Should the file be written directly, or should it be written
> to a lockfile and renamed into place only when complete?
I do not think we care that deeply either way, as we do not want to
run multiple auto-gc's at the same time in the first place. So either
one of the following is perfectly fine:
* We open the final destination directly, but with O_CREAT|O_EXCL,
which as a side effect also detects the simultanous execution
[*1*]. We do not do any "finalizing rename" if we go this route.
When we are done, close it and remove it if we did not write
anything, or leave it there if we did write something.
* We open a lockfile the usual way. When we are done, close it and
and remove it if we did not write anything, or finalize it by
renaming it if we did write something.
I think Duy's code wants to do the latter.
> This doesn't seem like a common thing to want (as in, this might be the
> only caller), but it probably makes sense to build it into the
> tempfile/lockfile API nevertheless, because implementing it externally
> would require a lot of other code to be duplicated.
>
> Another possibility that might work (maybe without requiring changes to
> tempfile/lockfile): don't worry about deleting the log file if it is
> empty, but make observers treat an empty log file the same as an absent one.
Probably your "don't remove and check for emptiness" approach would
be the simpler of the two, but I think we can go either way.
Thanks.
[Footnote]
*1* But one "gc" could be foreground gc that does not write to a log
file and the other "gc" could be background that does write to a
log file, so this cannot be the primary way to avoid double
execution.
next prev parent reply other threads:[~2015-09-16 16:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-08 12:28 Since gc.autodetach=1 you can end up with auto-gc on every command with no user notification Ævar Arnfjörð Bjarmason
2015-07-08 12:47 ` Duy Nguyen
2015-08-22 2:12 ` [PATCH v3] gc: save log from daemonized gc --auto and print it next time Nguyễn Thái Ngọc Duy
2015-08-25 17:49 ` Junio C Hamano
2015-08-31 10:17 ` Duy Nguyen
2015-09-13 1:36 ` [PATCH v4] " Nguyễn Thái Ngọc Duy
2015-09-14 17:24 ` Junio C Hamano
2015-09-14 17:37 ` Junio C Hamano
2015-09-16 9:28 ` Michael Haggerty
2015-09-16 16:00 ` Junio C Hamano [this message]
2015-09-17 9:40 ` Michael Haggerty
2015-09-17 13:08 ` Duy Nguyen
2015-09-17 14:48 ` Junio C Hamano
2015-09-19 5:13 ` [PATCH v5] " Nguyễn Thái Ngọc Duy
2015-09-21 16:43 ` Junio C Hamano
2015-09-19 5:14 ` [Alt. PATCH " Nguyễn Thái Ngọc Duy
2015-09-21 16:19 ` Junio C Hamano
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=xmqqmvwms6b1.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=mhagger@alum.mit.edu \
--cc=pclouds@gmail.com \
--cc=sunshine@sunshineco.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.