Jeff King p...@peff.net 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
Jeff King p...@peff.net 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 Wed, May 20, 2015 at 10:25:41AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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
On Tue, May 19, 2015 at 12:48:21PM -0700, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com 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
Jim Hill gjth...@gmail.com 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
5 matches
Mail list logo
