On Wed, May 20, 2015 at 10:25:41AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Not related to your patch, but I've often wondered if we can just get
> > rid of hold_lock_file_for_append. There's exactly one caller, and I
> > think it is doing the wrong thing. It is add_to_alternates_f
Jeff King writes:
> Not related to your patch, but I've often wondered if we can just get
> rid of hold_lock_file_for_append. There's exactly one caller, and I
> think it is doing the wrong thing. It is add_to_alternates_file(), but
> shouldn't it probably read the existing lines to make sure it
Jeff King writes:
> Your revised patch 2 looks good to me. I think you could test it more
> reliably by simply adding a larger file, like:
>
> test-genrandom foo $((128 * 1024 + 1)) >big &&
> echo 'big filter=epipe' >.gitattributes &&
> git config filter.epipe.clean true &&
> git add big
On Tue, May 19, 2015 at 12:48:21PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Yuck; please discard the previous one. write_in_full() side is also
> > writing into that process, so we should do the same.
>
> OK, without these two, and with the "true" filter that does not read
>
Jim Hill writes:
> +test_expect_success "filter: smudge empty file" '
> + git config filter.empty-in-repo.clean true &&
But this one is correct but tricky ;-)
If the contents to be cleaned is small enough (i.e. the one-liner
file used in this test) to fit in the pipe buffer and we feed the
5 matches
Mail list logo
