On Wed, Nov 04, 2015 at 02:08:21PM -0600, Doug Kelly wrote:
> On Wed, Nov 4, 2015 at 2:02 PM, Jeff King wrote:
> > Definitely cleaning up the .bitmap is sane and not racy (it's in the
> > same boat as the .idx, I think).
> >
> > .keep files are more tricky. I'd have to go over the
On Wed, Nov 4, 2015 at 1:35 PM, Junio C Hamano wrote:
> Doug Kelly writes:
>
>> I think the patches I sent (a bit prematurely) address the
>> remaining comments... I did find there was a relevant test in
>> t5304 already, so I added a new test in the same
On Wed, Nov 04, 2015 at 11:35:52AM -0800, Junio C Hamano wrote:
> Doug Kelly writes:
>
> > I think the patches I sent (a bit prematurely) address the
> > remaining comments... I did find there was a relevant test in
> > t5304 already, so I added a new test in the same
On Wed, Nov 04, 2015 at 01:56:38PM -0600, Doug Kelly wrote:
> > I did wonder if we want to say anything about .bitmap files, though.
> > If there is one without matching .idx and .pack, shouldn't we report
> > just like we report .idx without .pack (or vice versa)?
>
> I think you're right --
On Wed, Nov 4, 2015 at 2:02 PM, Jeff King wrote:
> On Wed, Nov 04, 2015 at 01:56:38PM -0600, Doug Kelly wrote:
>
>> > I did wonder if we want to say anything about .bitmap files, though.
>> > If there is one without matching .idx and .pack, shouldn't we report
>> > just like we
On Wed, Nov 04, 2015 at 02:08:21PM -0600, Doug Kelly wrote:
> Currently there's no mtime-guarding logic (I dug up that conversation
> earlier, though, but after I'd done the respin on this series)... OK,
> in that case, I'll create a separate patch that tests/cleans up
> .bitmap, but doesn't
Doug Kelly writes:
> I think the patches I sent (a bit prematurely) address the
> remaining comments... I did find there was a relevant test in
> t5304 already, so I added a new test in the same section (and
> cleaned up some of the garbage it wasn't removing before). I'm
>
On Wed, Oct 28, 2015 at 5:43 PM, Doug Kelly wrote:
> On Wed, Oct 28, 2015 at 12:48 PM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>>> Eric Sunshine writes:
>>>
> -static void
Junio C Hamano writes:
> Eric Sunshine writes:
>
>>> -static void real_report_garbage(const char *desc, const char *path)
>>> +const char *bits_to_msg(unsigned seen_bits)
>>
>> If you don't expect other callers outside this file, then this should
>>
On Wed, Oct 28, 2015 at 12:48 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Eric Sunshine writes:
>>
-static void real_report_garbage(const char *desc, const char *path)
+const char *bits_to_msg(unsigned
Eric Sunshine sunsh...@sunshineco.com writes:
-static void real_report_garbage(const char *desc, const char *path)
+const char *bits_to_msg(unsigned seen_bits)
If you don't expect other callers outside this file, then this should
be declared 'static'. If you do expect future external
From: Junio C Hamano gits...@pobox.com
The hook to report garbage files in $GIT_OBJECT_DIRECTORY/pack/
could be generic but is too specific to count-object's needs.
Move the part to produce human-readable messages to count-objects,
and refine the interface to callback with the bits with values
On Thu, Aug 13, 2015 at 2:02 PM, Doug Kelly dougk@gmail.com wrote:
From: Junio C Hamano gits...@pobox.com
The hook to report garbage files in $GIT_OBJECT_DIRECTORY/pack/
could be generic but is too specific to count-object's needs.
Move the part to produce human-readable messages to
13 matches
Mail list logo