From: Jeff King <peff@peff.net>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: Junio C Hamano <gitster@pobox.com>,
Johan Herland <johan@herland.net>,
Ramsay Jones <ramsay@ramsay1.demon.co.uk>,
git@vger.kernel.org
Subject: Re: [PATCH v2 04/12] refs: implement simple transactions for the packed-refs file
Date: Thu, 20 Jun 2013 15:55:26 -0400 [thread overview]
Message-ID: <20130620195526.GA31364@sigill.intra.peff.net> (raw)
In-Reply-To: <51C343FF.6030002@alum.mit.edu>
On Thu, Jun 20, 2013 at 08:03:43PM +0200, Michael Haggerty wrote:
> > I noticed that recently, too. I have a patch series about 90% complete
> > that abstracts the tempfile handling (the ultimate goal of which is to
> > optionally clean up tmp_* files in the objects/ directory). It refactors
> > the lockfile cleanup, and it would not be too hard to have a committed
> > or rolled-back lockfile actually remove itself from the "to clean at
> > exit" list.
> >
> > Which would make it perfectly safe to have a lockfile as an automatic
> > variable as long as you commit or rollback before leaving the function.
>
> Cool, then I won't work on that. You might also have to make the
> lockfile list into a doubly-linked-list to avoid having to do a linear
> scan to find the entry to delete, unless the total number of entries is
> known to remain small.
Yes, I noticed that potential issue, but I don't think it is worth
worrying about. We typically only take one lock at a time, or a handful
of tempfiles (e.g., one object at a time, or two files for diff).
And once it's abstracted out, it would be easy to handle later.
The part I am a little stuck on is plugging it into
pack-objects/index-pack. Their output handling is a little convoluted
because they may be writing to stdout, to a tempfile, to a named file,
or even appending to an existing file in the case of index-pack
--fix-thin. I don't think it's unmanageable, but I need to spend some
more time on the refactoring.
> Please CC me on the patch series when it is done.
Will do.
-Peff
next prev parent reply other threads:[~2013-06-20 19:55 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-19 7:51 [PATCH v2 00/12] Fix some reference-related races Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 01/12] repack_without_ref(): split list curation and entry writing Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 02/12] pack_refs(): split creation of packed refs " Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 03/12] refs: wrap the packed refs cache in a level of indirection Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 04/12] refs: implement simple transactions for the packed-refs file Michael Haggerty
2013-06-19 19:18 ` Junio C Hamano
2013-06-20 7:49 ` Michael Haggerty
2013-06-20 11:55 ` Jeff King
2013-06-20 18:03 ` Michael Haggerty
2013-06-20 19:55 ` Jeff King [this message]
2013-06-20 17:11 ` Junio C Hamano
2013-06-20 17:58 ` Michael Haggerty
2013-06-20 18:36 ` Junio C Hamano
2013-06-19 7:51 ` [PATCH v2 05/12] refs: manage lifetime of packed refs cache via reference counting Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 06/12] do_for_each_entry(): increment the packed refs cache refcount Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 07/12] packed_ref_cache: increment refcount when locked Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 08/12] Extract a struct stat_data from cache_entry Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 09/12] add a stat_validity struct Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 10/12] get_packed_ref_cache: reload packed-refs file when it changes Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 11/12] for_each_ref: load all loose refs before packed refs Michael Haggerty
2013-06-19 7:51 ` [PATCH v2 12/12] refs: do not invalidate the packed-refs cache unnecessarily Michael Haggerty
2013-06-19 18:56 ` [PATCH v2 00/12] Fix some reference-related races Jeff King
2013-06-20 9:09 ` Michael Haggerty
2013-06-20 11:52 ` Jeff King
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=20130620195526.GA31364@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johan@herland.net \
--cc=mhagger@alum.mit.edu \
--cc=ramsay@ramsay1.demon.co.uk \
/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).