On Tue, Aug 7, 2012 at 2:44 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> I still think your 2/2 is worth doing independently, though. It is silly
>> that git-prune will not mention pruned objects without "-v", but will
>> mention temporary files. They should be in the same category.
>
> Ok,
On Tue, Aug 07, 2012 at 02:44:51PM -0700, Junio C Hamano wrote:
> Ok, so I'll queue it as a separate topic with a different
> justification.
>
> -- >8 --
> From: Brandon Casey
> Date: Mon, 6 Aug 2012 22:01:49 -0700
> Subject: [PATCH] prune.c: only print informational message in show_only or
> v
Jeff King writes:
> I still think your 2/2 is worth doing independently, though. It is silly
> that git-prune will not mention pruned objects without "-v", but will
> mention temporary files. They should be in the same category.
Ok, so I'll queue it as a separate topic with a different
justifica
Brandon Casey writes:
> On Mon, Aug 6, 2012 at 11:03 PM, Jeff King wrote:
>> On Mon, Aug 06, 2012 at 10:44:07PM -0700, Brandon Casey wrote:
>>> Anyone else? :)
>>
>> Sorry to gang up on you. :)
>
> Heh. :b
>
>> I still think your 2/2 is worth doing independently, though. It is silly
>> that git-
On Mon, Aug 6, 2012 at 11:03 PM, Jeff King wrote:
> On Mon, Aug 06, 2012 at 10:44:07PM -0700, Brandon Casey wrote:
>> Anyone else? :)
>
> Sorry to gang up on you. :)
Heh. :b
> I still think your 2/2 is worth doing independently, though. It is silly
> that git-prune will not mention pruned object
On Mon, Aug 06, 2012 at 10:44:07PM -0700, Brandon Casey wrote:
> On Mon, Aug 6, 2012 at 10:32 PM, Jeff King wrote:
> >
> > This seems like a band-aid. The real problem is that auto-gc can
> > interfere with the pack protocol, which it should not be allowed to do,
> > no matter what it produces.
>
On Mon, Aug 6, 2012 at 10:34 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> Ok, now a tested patch, on top of your 1/2
On Mon, Aug 6, 2012 at 10:32 PM, Jeff King wrote:
>
> This seems like a band-aid. The real problem is that auto-gc can
> interfere with the pack protocol, which it sho
Junio C Hamano writes:
> Note that this chooses to expose what comes out of the standard
> output of the subprocess to the standard error to be shown to the
> user sitting on the other end. This is in line with what we do to
> all of our hooks (Cf. cd83c74 (Redirect update hook stdout to
> stder
On Mon, Aug 06, 2012 at 10:01:49PM -0700, Brandon Casey wrote:
> This informational message can cause a problem if 'git prune' is spawned
> from an auto-gc during receive-pack. In this case, the informational
> message will be sent back over the wire to the git client and the client
> will try to
Thanks.
This patch may fix the immediate symptom, but I think the right fix
is to correct the way "gc" is invoked by receive-pack, so that
nothing "gc" writes to its standard output can leak to the standard
output of the receive-pack. After all, receive-pack is the one that
knows that its output
This informational message can cause a problem if 'git prune' is spawned
from an auto-gc during receive-pack. In this case, the informational
message will be sent back over the wire to the git client and the client
will try to interpret it as part of the pack protocol and will produce an
error.
S
11 matches
Mail list logo
