From: Kjetil Barvik <barvik@broadpark.no>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/6] "git repack -a -d" improvements
Date: Sat, 28 Feb 2009 13:29:12 +0100 [thread overview]
Message-ID: <8663iuwxrb.fsf@broadpark.no> (raw)
In-Reply-To: <cover.1235812035.git.gitster@pobox.com>
* Junio C Hamano <gitster@pobox.com> writes:
| [2/6] refactors public interface has_sha1_pack() that takes an optional
| "ignore_packed" list. Most callers pass NULL, so it introduces a new
| function has_sha1_kept_pack() and migrate the minority caller to this
| interface while losing the argument from the original function and callers
| that currently pass NULL.
[...]
| [4/6] identifies three places that use "ignore_packed" list to tell if a
| pack is on the list or not, and introduces a helper function to do so.
| The helper is conveniently called is_kept_pack(), even though at this
| stage the list does not necessarily mean a list of "unkept" packs yet.
OK, patch 2/6 failed for me when I was doing 'git am' to import the
patch-series, so sorry if do not see all bits of the patch correctly.
Would it be an improvment to change the signature of the currently
find_sha1_pack() function to:
struct packed_git *
find_pack_entry(const unsigned char *sha1, off_t *sha1_pack_offset,
struct packed_git *packs)
- The currently existing 'struct pack_entry *e' parameter is only
used to retrn the offset, so make it more clear. The struct
pack_entry can probably be deleted from the sha1_file.c file.
- When the 'git repack -a -d' command is used, one has to compute
the list of allowed pack-files to look into, and give this list to
find_pack_entry().
- The currently named find_sha1_pack() function can then be deleted.
- For example, when this function is now used in sha1_object_info()
it can be called like this:
found_pack = find_pack_entry(sha1, &offset, packed_git);
-- kjetil
next prev parent reply other threads:[~2009-02-28 12:36 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-19 20:24 Really slow 'git gc' Linus Torvalds
2009-02-19 21:14 ` Junio C Hamano
2009-02-19 21:25 ` Linus Torvalds
2009-02-28 9:15 ` [PATCH 0/6] "git repack -a -d" improvements Junio C Hamano
2009-02-28 9:15 ` [PATCH 1/6] git-repack: resist stray environment variable Junio C Hamano
2009-02-28 9:15 ` [PATCH 2/6] has_sha1_pack(): refactor "pretend these packs do not exist" interface Junio C Hamano
2009-02-28 9:15 ` [PATCH 3/6] has_sha1_kept_pack(): take "struct rev_info" Junio C Hamano
2009-02-28 9:15 ` [PATCH 4/6] Consolidate ignore_packed logic more Junio C Hamano
2009-02-28 9:15 ` [PATCH 5/6] Simplify is_kept_pack() Junio C Hamano
2009-02-28 9:15 ` [PATCH 6/6] is_kept_pack(): final clean-up Junio C Hamano
2009-02-28 12:29 ` Kjetil Barvik [this message]
2009-02-28 17:41 ` [PATCH 0/6] "git repack -a -d" improvements Junio C Hamano
[not found] ` <7Vazs5mFk91IKAarOd0wrBNmYj7eSJxVIcR0PEQxJl8R0aQmQDEqSJMphMrXhmVu570fijupQ34@cipher.nrlssc.navy.mil>
2009-03-18 20:59 ` [PATCH] t7700-repack: repack -a now works properly, expect success from test Brandon Casey
2009-03-20 3:47 ` [PATCH 0/5] repack improvements Brandon Casey
2009-03-20 3:47 ` [PATCH 1/5] t7700-repack: add two new tests demonstrating repacking flaws Brandon Casey
2009-03-20 3:47 ` [PATCH 2/5] git-repack.sh: don't use --kept-pack-only option to pack-objects Brandon Casey
2009-03-20 3:47 ` [PATCH 3/5] pack-objects: only repack or loosen objects residing in "local" packs Brandon Casey
2009-03-20 3:47 ` [PATCH 4/5] t7700-repack: repack -a now works properly, expect success from test Brandon Casey
2009-03-20 3:47 ` [PATCH 5/5] Remove --kept-pack-only option and associated infrastructure Brandon Casey
2009-03-20 4:05 ` [PATCH 0/5] repack improvements Brandon Casey
2009-02-19 21:34 ` Really slow 'git gc' 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=8663iuwxrb.fsf@broadpark.no \
--to=barvik@broadpark.no \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.