> On 02 Nov 2016, at 19:20, Jeff King wrote:
>
> The rot13-filter.pl script hardcodes "#!/usr/bin/perl", and
> does not respect $PERL_PATH at all. That is a problem if the
> system does not have perl at that path, or if it has a perl
> that is too old to run a complicated script like the
> rot13
> On 06 Nov 2016, at 15:29, Jeff King wrote:
>
> On Sun, Nov 06, 2016 at 03:25:33PM +0100, Lars Schneider wrote:
>
>> This looks good to me (and it works on my machine).
>> However, I took a look at the "write_script" function and found this,
>> added
> On 02 Nov 2016, at 19:18, Jeff King wrote:
>
> We create a rot13.sh script in the trash directory, but need
> to call it by its full path when we have moved our cwd to
> another directory. Let's just put $TEST_ROOT in our $PATH so
> that the script is always found.
>
> This is a minor conveni
> On 02 Nov 2016, at 19:17, Jeff King wrote:
>
> This avoids us fooling around with $SHELL_PATH and the
> executable bit ourselves.
>
> Signed-off-by: Jeff King
> ---
> t/t0021-conversion.sh | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/t/t0021-conversion.sh b/t/t
> On 21 Oct 2016, at 14:24, Johannes Schindelin
> wrote:
>
> When we came up with the "sequencer" idea, we really wanted to have
> kind of a plumbing equivalent of the interactive rebase. Hence the
> choice of words: the "todo" script, a "pick", etc.
>
> ...
>
> Signed-off-by: Johannes Schind
> On 2 Nov 2016, at 17:43, Johannes Sixt wrote:
>
> Am 02.11.2016 um 18:04 schrieb Torsten Bögershausen:
>>> * ls/filter-process (2016-10-17) 14 commits
>>> (merged to 'next' on 2016-10-19 at ffd0de042c)
>>
>> Some (late, as I recently got a new battery for the Mac OS 10.6 test system)
>> com
> On 2 Nov 2016, at 18:03, Johannes Sixt wrote:
>
>> Am 17.10.2016 um 01:20 schrieb larsxschnei...@gmail.com:
>> +# Compare two files and ensure that `clean` and `smudge` respectively are
>> +# called at least once if specified in the `expect` file. The actual
>> +# invocation count is not relev
On 2 Nov 2016, at 17:04, Torsten Bögershausen wrote:
>> * ls/filter-process (2016-10-17) 14 commits
>> (merged to 'next' on 2016-10-19 at ffd0de042c)
>
> Some (late, as I recently got a new battery for the Mac OS 10.6 test system)
> comments:
> t0021 failes here:
>
>
> Can't locate object m
> On 25 Oct 2016, at 20:16, Junio C Hamano wrote:
>
> Here is to make sure everybody is on the same page regarding the
> series. The patches are adjusted for comments from Eric and Dscho.
Thank you, Junio! Your v3 looks good to me and I compiled and tested
it on Windows.
There is one catch th
> On 24 Oct 2016, at 21:22, Johannes Sixt wrote:
>
> Am 24.10.2016 um 20:03 schrieb larsxschnei...@gmail.com:
>> From: Lars Schneider
>>
>> This fixes "convert: add filter..process option" (edcc8581) on
>> Windows.
>
> Today's next f
> On 21 Oct 2016, at 12:41, Jeff King wrote:
>
> On Fri, Oct 21, 2016 at 04:43:48AM -0400, Jeff King wrote:
>
>> The obvious fix would be to send "--verbose" output to stderr, but I
>> suspect that would end up annoying for people who do:
>>
>> ./t5547-push-quarantine.sh -v | less
>>
>> to r
> On 21 Oct 2016, at 06:08, Johannes Schindelin
> wrote:
>
> Hi Junio & Lars,
>
> On Thu, 20 Oct 2016, Junio C Hamano wrote:
>
>> * ls/filter-process (2016-10-17) 14 commits
>> (merged to 'next' on 2016-10-19 at ffd0de042c)
>> + contrib/long-running-filter: add long running filter example
>>
Hi,
on TravisCI I see these weird "Tests out of sequence" errors with prove
and they seem to not go away. I assume the reason that they not go away
is that the ".prove" file is carried over from on build to another (but I can't
look into this file on TravisCI).
Has anyone an idea where these err
> On 17 Oct 2016, at 15:28, Junio C Hamano wrote:
> ...
>
> * ls/filter-process (2016-10-17) 14 commits
> - contrib/long-running-filter: add long running filter example
> - convert: add filter..process option
> - convert: prepare filter..process option
> - convert: make apply_filter() adhere to
Hi,
Git attributes for path names are generally case sensitive. However, on
a case insensitive file system (e.g. macOS/Windows) they appear to be
case insensitive (`*.bar` would match `foo.bar` and `foo.BAR`). That
works great until a Git users joins the party with a case sensitive file
system.
> On 11 Oct 2016, at 03:09, Torsten Bögershausen wrote:
>
> On Tue, Oct 11, 2016 at 10:11:22AM +0200, Lars Schneider wrote:
>>
>>> On 10 Oct 2016, at 21:58, Junio C Hamano wrote:
>>>
>>> larsxschnei...@gmail.com writes:
>>>
>>>
> On 16 Oct 2016, at 01:03, Johannes Schindelin
> wrote:
>
> Hi Lars,
>
> On Sat, 15 Oct 2016, Lars Schneider wrote:
>
>>
>>> On 11 Oct 2016, at 05:12, Johannes Schindelin
>>> wrote:
>>>
>>> On Windows, pid_t
> On 15 Oct 2016, at 14:01, Ramsay Jones wrote:
>
>
>
> On 15/10/16 16:05, Lars Schneider wrote:
>>> On 11 Oct 2016, at 16:46, Ramsay Jones wrote:
> [snip]
>>> -void stop_multi_file_filter(struct child_process *process)
>>> +static void stop_mu
> On 11 Oct 2016, at 16:46, Ramsay Jones wrote:
>
> If you need to re-roll your 'ls/filter-process' branch, could you
> please squash this into commit 85290197
> ("convert: add filter..process option", 08-10-2016).
>
>
> -void stop_multi_file_filter(struct child_process *process)
> +static voi
> On 11 Oct 2016, at 05:12, Johannes Schindelin
> wrote:
>
> Hi Lars,
>
> On Sat, 8 Oct 2016, larsxschnei...@gmail.com wrote:
>
>> @@ -31,6 +32,15 @@ static void cleanup_children(int sig, int in_signal)
>> while (children_to_clean) {
>> struct child_to_clean *p = children_to
> On 08 Oct 2016, at 22:42, Torsten Bögershausen wrote:
>
> On 08.10.16 13:25, larsxschnei...@gmail.com wrote:
>> From: Lars Schneider
>>
>> Add a simple pass-thru filter as example implementation for the Git
>> filter protocol version 2. See Documen
@Peff: If you have time, it would be great if you could comment on
one question below prefixed with "@Peff". Thanks!
> On 12 Oct 2016, at 03:54, Jakub Narębski wrote:
>
> W dniu 12.10.2016 o 00:26, Lars Schneider pisze:
>>> On 09 Oct 2016, at 01:06, Jakub Narębski
> On 09 Oct 2016, at 01:06, Jakub Narębski wrote:
>
> Part 1 of review, starting with the protocol v2 itself.
>
> W dniu 08.10.2016 o 13:25, larsxschnei...@gmail.com pisze:
>> From: Lars Schneider
>>
>> +upon checkin. By default these commands process onl
> On 09 Oct 2016, at 07:32, Torsten Bögershausen wrote:
>
> On 09.10.16 01:06, Jakub Narębski wrote:
>>> +
+packet: git< status=abort
+packet: git<
+
+
+After the filter has processed a blob it is exp
> On 10 Oct 2016, at 21:58, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
> [...]
>> +# Count unique lines except clean invocations in two files and compare
>> +# them. Clean invocations are not counted because their number can vary.
>> +# c.f.
>> http://public-inbox.org/git/xmq
> On 04 Oct 2016, at 23:00, Jakub Narębski wrote:
>
> [Some of answers and comments may got invalidated by v9]
>
> W dniu 30.09.2016 o 21:38, Lars Schneider pisze:
>>> On 27 Sep 2016, at 17:37, Jakub Narębski wrote:
>>>
>>> Part second of the
> On 04 Oct 2016, at 22:50, Jakub Narębski wrote:
>
> [Some of answers may get invalidated by v9]
>
> W dniu 30.09.2016 o 20:56, Lars Schneider pisze:
>>> On 27 Sep 2016, at 00:41, Jakub Narębski wrote:
>>>
>>>> +
>>>> +After t
> On 04 Oct 2016, at 21:04, Jakub Narębski wrote:
>
> W dniu 03.10.2016 o 19:13, Lars Schneider pisze:
>>> On 01 Oct 2016, at 22:48, Jakub Narębski wrote:
>>> W dniu 01.10.2016 o 20:59, Lars Schneider pisze:
>>>> On 29 Sep 2016, at 23:27, Junio C Hama
> On 06 Oct 2016, at 11:32, Johannes Schindelin
> wrote:
>
> Hi Junio & Lars,
>
> On Wed, 5 Oct 2016, Junio C Hamano wrote:
>
>> Lars Schneider writes:
>>
>>> OK. Something like the patch below would work nicely.
>>
>> Yeah,
> On 04 Oct 2016, at 21:30, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> The flag 'clean_on_exit' kills child processes spawned by Git on exit.
>> A hard kill like this might not be desired in all cas
> On 04 Oct 2016, at 21:33, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>>
>> +static int packet_write_gently(const int fd_out, const char *buf, size_t
>> size)
>> +{
>> +static char packe
> On 04 Oct 2016, at 21:53, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>
>> +int write_packetized_from_buf(const char *src_in, size_t len, int fd_out)
>> +{
>> +static char buf[LARGE_PACKET_D
> On 04 Oct 2016, at 00:31, Junio C Hamano wrote:
>
>
> * ls/filter-process (2016-09-23) 11 commits
> - convert: add filter..process option
> - convert: make apply_filter() adhere to standard Git error handling
> - convert: modernize tests
> - convert: quote filter names in error messages
> - p
Hi,
If there is a conflict in the .gitattributes during a merge then it looks
like as if the attributes are not applied (which kind of makes sense as Git
would not know what to do). As a result Git can treat e.g. binary files
as text and they can end up with changed line endings in the working
> On 03 Oct 2016, at 19:02, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> If the filter process refuses to die forever when Git told it to
>>> shutdown (by closing the pipe to it, for example), that filter
>>> process is simply buggy. I
> On 01 Oct 2016, at 22:48, Jakub Narębski wrote:
>
> W dniu 01.10.2016 o 20:59, Lars Schneider pisze:
>> On 29 Sep 2016, at 23:27, Junio C Hamano wrote:
>>> Lars Schneider writes:
>>>
>>> If the filter process refuses to die forever when Git told
> On 29 Sep 2016, at 23:27, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>> We discussed that issue in v4 and v6:
>> http://public-inbox.org/git/20160803225313.pk3tfe5ovz4y3...@sigill.intra.peff.net/
>> http://public-inbox.org/git/xmqqbn0a3wy3@gitster.
> On 29 Sep 2016, at 01:14, Jakub Narębski wrote:
>
> Part third (and last) of the review of v8 11/11.
>
> W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com napisał:
>
>
>> @@ -31,7 +31,10 @@ test_expect_success setup '
>> cat test >test.i &&
>> git add test test.t test.i &&
>>
> On 27 Sep 2016, at 17:37, Jakub Narębski wrote:
>
> Part second of the review of 11/11.
>
> W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze:
>
>> +
>> +if (!drv->process && (CAP_CLEAN & wanted_capability) && drv->clean)
>
> This is just a very minor nitpicking, but wouldn't it
> On 27 Sep 2016, at 00:41, Jakub Narębski wrote:
>
> Part first of the review of 11/11.
>
> W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze:
>> From: Lars Schneider
>>
>> diff --git a/Documentation/gitattributes.txt
>> b/Documentation/gita
> On 29 Sep 2016, at 18:57, Junio C Hamano wrote:
>
> Torsten Bögershausen writes:
>
>>> 1) Git exits
>>> 2) The filter process receives EOF and prints "STOP" to the log
>>> 3) t0021 checks the content of the log
>>>
>>> Sometimes 3 happened before 2 which makes the test fail.
>>> (Example: h
> On 29 Sep 2016, at 18:57, Junio C Hamano wrote:
>
> Torsten Bögershausen writes:
>
>>> 1) Git exits
>>> 2) The filter process receives EOF and prints "STOP" to the log
>>> 3) t0021 checks the content of the log
>>>
>>> Sometimes 3 happened before 2 which makes the test fail.
>>> (Example: h
> On 28 Sep 2016, at 23:49, Junio C Hamano wrote:
>
> I suspect that you are preparing a reroll already, but the one that
> is sitting in 'pu' seems to be flaky in t/t0021 and I seem to see
> occasional failures from it.
>
> I didn't trace where the test goes wrong, but one easy mistake you
> c
> On 27 Sep 2016, at 11:00, Jeff King wrote:
>
> On Tue, Sep 27, 2016 at 10:14:16AM +0200, Lars Schneider wrote:
>
>>>>> + strbuf_grow(sb_out, PKTLINE_DATA_MAXLEN+1);
>>>>> + paket_len = packet_read(fd_in, NULL, NULL,
>>
On 26 Sep 2016, at 22:23, Lars Schneider wrote:
>
> On 25 Sep 2016, at 15:46, Jakub Narębski wrote:
>
>> W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze:
>>> From: Lars Schneider
>
>
>>> + strbuf_grow(sb_out, PKTLINE_DA
On 25 Sep 2016, at 15:46, Jakub Narębski wrote:
> W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze:
>> From: Lars Schneider
>> +{
>> +static char buf[PKTLINE_DATA_MAXLEN];
>
> Sidenote: we have LARGE_PACKET_MAX (used in previous patch), bu
On 25 Sep 2016, at 13:26, Jakub Narębski wrote:
> W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze:
>> From: Lars Schneider
>> ...
>>
>> +static int packet_write_gently(const int fd_out, const char *buf, size_t
>> size)
>
> I'm not sure
On 24 Sep 2016, at 23:22, Jakub Narębski wrote:
> W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze:
>
>> From: Lars Schneider
>>
>> Subject: [PATCH v8 02/11] pkt-line: extract set_packet_header()
>>
>> set_packet_header() converts an integer
On 24 Sep 2016, at 23:14, Jakub Narębski wrote:
> Hello Lars,
>
> W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze:
>
>> From: Lars Schneider
>>
>> packet_write() should be called packet_write_fmt() as the string
>> parameter can be formatted.
> On 25 Sep 2016, at 00:12, Jakub Narębski wrote:
>
> W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze:
>> From: Lars Schneider
>>
>> Move check_pipe() to run_command and make it public. This is necessary
>> to call the function from pkt-line in a
> On 23 Sep 2016, at 19:13, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> If you need to re-roll your 'ls/filter-process' branch, could you please
>>> squash this into the relevant commit c42a4cbc ("run-command: move
>>> check_pi
> On 22 Sep 2016, at 18:56, Ramsay Jones wrote:
>
>
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Lars,
>
> If you need to re-roll your 'ls/filter-process' branch, could you please
> squash this into the relevant commit c42a4cbc ("run-command: move check_pipe()
> from write_or_die to run_comman
> On 21 Sep 2016, at 18:42, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> On 21 Sep 2016, at 11:31, stefan.na...@atlas-elektronik.com wrote:
>>>
>>> In the Subject: s/the //
>>>
>>> Am 21.09.2016 um 10:45 schrieb larsxschne
> On 21 Sep 2016, at 11:31, stefan.na...@atlas-elektronik.com wrote:
>
> In the Subject: s/the //
>
> Am 21.09.2016 um 10:45 schrieb larsxschnei...@gmail.com:
>> From: Lars Schneider
>>
>> The TravisCI macOS build is broken because homebrew (a macOS depe
> On 15 Sep 2016, at 23:17, Ori Rawlings wrote:
>
> Importing a long history from Perforce into git using the git-p4 tool
> can be especially challenging. The `git p4 clone` operation is based
> on an all-or-nothing transactionality guarantee. Under real-world
> conditions like network unreliabi
> On 15 Sep 2016, at 21:44, Jeff King wrote:
>
> On Thu, Sep 15, 2016 at 05:42:58PM +0100, Lars Schneider wrote:
>
>>>>>> +int packet_flush_gently(int fd)
>>>>>> +{
>>>>>> +packet_trace("", 4, 1);
>>&
> On 13 Sep 2016, at 17:22, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> diff --git a/contrib/long-running-filter/example.pl
>> b/contrib/long-running-filter/example.pl
>> ...
>> +sub packet_read {
>> +my $buffer;
>> +my $bytes_read = read STDIN, $buffer, 4;
>> +
> On 13 Sep 2016, at 17:42, Junio C Hamano wrote:
>
> Torsten Bögershausen writes:
>
>> I would really consider to treat pathnames as binary, and not add a trailing
>> '\n',
>> are there other opinions ?
>
> It would be the most consistent if the same format as
> write_name_quoted() is used
> On 14 Sep 2016, at 14:31, Ramsay Jones wrote:
>
>
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Lars,
>
> If you need to re-roll your 'ls/filter-process' branch, could you
> please squash this into the relevant patch; commit 2afd9b22
> ("pkt-line: add packet_write_gently()", 08-09-2016).
>
>
> On 13 Sep 2016, at 23:44, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> On 13 Sep 2016, at 00:30, Junio C Hamano wrote:
>>>
>>> larsxschnei...@gmail.com writes:
>>>
>>>> From: Lars Schneider
>>>>
>
> On 13 Sep 2016, at 00:30, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> packet_flush() would die in case of a write error even though for some
>> callers an error would be acceptable. Add packet_flush_gentl
> On 10 Sep 2016, at 17:40, Torsten Bögershausen wrote:
>
> []
>
> One general question up here, more comments inline.
> The current order for a clean-filter is like this, I removed the error
> handling:
>
> int convert_to_git()
> {
> ret |= apply_filter(path, src, len, -1, dst, filter)
> On 13 Sep 2016, at 17:54, Jakub Narębski wrote:
>
> On 13 September 2016 at 18:15, David Bainbridge
> wrote:
>> Hi Jakub,
>>
>> You said:
>> P.S. At request I can open a separate channel in survey, with
>> a separate survey URL, so that responses from particular site
>> or organization could
> On 12 Sep 2016, at 21:11, Junio C Hamano wrote:
>
> [..]
> properly; supporting "huge objects" better in the object layer,
> without having to resort to ugly hacks like GitLFS that will never
> be part of the core Git. [...]
I agree with you that GitLFS is an ugly hack.
Some applications hav
> On 10 Sep 2016, at 08:29, Torsten Bögershausen wrote:
>
> On Thu, Sep 08, 2016 at 08:21:32PM +0200, larsxschnei...@gmail.com wrote:
> []
>> +packet: git> git-filter-client
>> +packet: git> version=2
>> +packet: git> version=42
>> +packet: git>
>> +packe
> On 11 Sep 2016, at 18:01, Stefan Beller wrote:
>
> On Sun, Sep 11, 2016 at 4:36 AM, Lars Schneider
> wrote:
>
>>>
>>> call check_pipe from write_or_die here instead of
>>> reproducing that function?
>> [...]
>
>> Maybe it would
> On 09 Sep 2016, at 00:05, Stefan Beller wrote:
>
> On Thu, Sep 8, 2016 at 11:21 AM, wrote:
>> From: Lars Schneider
>>
>> Use `test_config` to set the config, check that files are empty with
>> `test_must_be_empty`, compare files with `test_cmp`, a
> On 08 Sep 2016, at 23:49, Stefan Beller wrote:
>
> On Thu, Sep 8, 2016 at 11:21 AM, wrote:
>> From: Lars Schneider
>>
>> write_packetized_from_fd() and write_packetized_from_buf() write a
>> stream of packets. All content packets use the maximal packe
> On 08 Sep 2016, at 23:24, Stefan Beller wrote:
>
> On Thu, Sep 8, 2016 at 11:21 AM, wrote:
>
>>
>> Add packet_write_gently() which writes arbitrary data and returns `0`
>> for success and `-1` for an error.
>
> I think documenting the return code is better done in either the header file
>
> On 08 Sep 2016, at 23:18, Stefan Beller wrote:
>
> On Thu, Sep 8, 2016 at 11:21 AM, wrote:
>
>> +static int packet_write_fmt_1(int fd, int gently,
>> + const char *fmt, va_list args)
>> +{
>> + struct strbuf buf = STRBUF_INIT;
>> + size_t count;
>> +
> On 07 Sep 2016, at 20:23, Junio C Hamano wrote:
>
> Eric Wong writes:
>
>> We probably should be using O_NOATIME for all O_RDONLY cases
>> to get the last bit of performance out (especially since
>> non-modern-Linux systems probably still lack relatime).
>
> No, please do not go there.
>
>
> On 06 Sep 2016, at 23:06, Eric Wong wrote:
>
> larsxschnei...@gmail.com wrote:
>> static int ce_compare_data(const struct cache_entry *ce, struct stat *st)
>> {
>> int match = -1;
>> -int fd = open(ce->name, O_RDONLY);
>> +int fd = open(ce->name, O_RDONLY | O_CLOEXEC);
>>
>>
> On 06 Sep 2016, at 13:38, Johannes Schindelin
> wrote:
>
> Hi Eric & Lars,
>
> On Mon, 5 Sep 2016, Eric Wong wrote:
>
>> larsxschnei...@gmail.com wrote:
>>> All processes that the Git main process spawns inherit the open file
>>> descriptors of the main process. These leaked file descriptor
> On 30 Aug 2016, at 22:46, Jakub Narębski wrote:
>
>>> The filter can exit right after the "error-all". If the filter does
>>> not exit then Git will kill the filter. I'll add this to the docs.
>>
>> OK.
>
> Is it explicit kill, or implicit kill: close pipe and end process?
I close the pipe
On 30 Aug 2016, at 20:59, Junio C Hamano wrote:
>
>> "abort" could be ambiguous because it could be read as "abort only
>> this file". "abort-all" would work, though. Would you prefer to see
>> "error" replaced by "abort" and "error-all" by "abort-all"?
>
> No.
>
> I was primarily reacting to
> On 30 Aug 2016, at 00:21, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> +In case the filter cannot or does not want to process the content,
>> +it is expected to respond with an "error" status. Depending on the
>> +`filter..required` flag Git will interpret that as error
>>
> On 29 Aug 2016, at 21:45, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>> I see. Thanks for the explanation.
>
> I expect the updated log message to explain the issue correctly
> then.
Sure!
>>> The parent is
>>> very likely to have pac
> On 29 Aug 2016, at 19:52, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> On 25 Aug 2016, at 21:17, Stefan Beller wrote:
>>>
>>>> On Thu, Aug 25, 2016 at 4:07 AM, wrote:
>>>> From: Lars Schneider
>>>>
>>
> On 29 Aug 2016, at 19:46, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
>> index 7b45136..34c8eb9 100755
>> --- a/t/t0021-conversion.sh
>> +++ b/t/t0021-conversion.sh
>> @@ -4,6 +4,15 @@ test_description='blob conver
> On 29 Aug 2016, at 20:05, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> Consider the case of a file that requires filtering and is present in
>> branch A but not in branch B. If A is the current HEAD and
> On 25 Aug 2016, at 13:07, larsxschnei...@gmail.com wrote:
>
> From: Lars Schneider
>
> The goal of this series is to avoid launching a new clean/smudge filter
> process for each file that is filtered.
>
> A short summary about v1 to v5 can be found here:
> htt
> On 26 Aug 2016, at 22:03, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> Use `test_config` to set the config, check that files are empty with
>> `test_must_be_empty`, compare files with `test_cmp`, and remove s
> On 26 Aug 2016, at 19:21, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>> OK, what function names would be more clear from your point of view?
>>
>> write_packetized_stream_from_fd()
>> write_packetized_stream_from_buf()
>>
> On 26 Aug 2016, at 19:15, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> Do you anticipate future need of non-gently variant of this
>>> function? If so, perhaps a helper that takes a boolean "am I
>>> working for the gently variant?&q
> On 26 Aug 2016, at 00:27, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> packet_write_stream_with_flush_from_fd() and
>> packet_write_stream_with_flush_from_buf() write a stream of packets. All
>> c
> On 25 Aug 2016, at 23:50, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> packet_write_fmt() has two shortcomings. First, it uses format_packet()
>> which lets the caller only send string data via "
> On 25 Aug 2016, at 23:41, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> packet_write_fmt() would die in case of a write error even though for
>> some callers an error would be acceptable. Add packet_write_fmt_
> On 25 Aug 2016, at 20:46, Stefan Beller wrote:
>
>> On Thu, Aug 25, 2016 at 4:07 AM, wrote:
>> From: Lars Schneider
>>
>> packet_write_stream_with_flush_from_fd() and
>> packet_write_stream_with_flush_from_buf() write a stream of packets. All
>> c
> On 25 Aug 2016, at 21:17, Stefan Beller wrote:
>
>> On Thu, Aug 25, 2016 at 4:07 AM, wrote:
>> From: Lars Schneider
>>
>> Generate more interesting large test files
>
> How are the large test files more interesting?
> (interesting in the notion of
> On 25 Aug 2016, at 20:59, Stefan Beller wrote:
>
>> On Thu, Aug 25, 2016 at 4:07 AM, wrote:
>> From: Lars Schneider
>>
>> According to LARGE_PACKET_MAX in pkt-line.h the maximal length of a
>> pkt-line packet is 65520 bytes. The pkt-line header takes 4
On 25 Aug 2016, at 20:12, Stefan Beller wrote:
>> +int packet_write_fmt_gently(int fd, const char *fmt, ...)
>> +{
>> + static struct strbuf buf = STRBUF_INIT;
>> + va_list args;
>> +
>> + strbuf_reset(&buf);
>> + va_start(args, fmt);
>> + format_packet(&buf, fmt, ar
> On 16 Aug 2016, at 22:48, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> On 30 Jul 2016, at 17:11, Brian Henderson wrote:
>>>
>>> ---
>>> contrib/diff-highlight/Makefile | 5 ++
>>> contrib/diff-highligh
> On 17 Aug 2016, at 14:41, Johannes Schindelin
> wrote:
>
> From: Ben Wijen
>
> When the index is locked and child processes inherit the handle to
> said lock and the parent process wants to remove the lock before the
> child process exits, on Windows there is a problem: it won't work
> beca
> On 30 Jul 2016, at 17:11, Brian Henderson wrote:
>
> ---
> contrib/diff-highlight/Makefile | 5 ++
> contrib/diff-highlight/t/Makefile| 19 +++
> contrib/diff-highlight/t/t9400-diff-highlight.sh | 63 ++
> contrib/diff-highlight/t/test-dif
> On 12 Aug 2016, at 19:13, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> If we do the success first and then error out halfway, we
>>> still have to clean up, so I do not see how this impacts
>>> implementation?
>>
>> That is
> On 12 Aug 2016, at 19:07, Stefan Beller wrote:
>
> On Fri, Aug 12, 2016 at 9:59 AM, Lars Schneider
> wrote:
>>
>> The welcome message is necessary to distinguish the long running
>> filter protocol (v2) from the current one-shot filter protocol (v1).
>>
> On 12 Aug 2016, at 18:48, Stefan Beller wrote:
>
> On Fri, Aug 12, 2016 at 9:38 AM, Jeff King wrote:
>> On Fri, Aug 12, 2016 at 09:33:18AM -0700, Stefan Beller wrote:
>>
If the result content is empty then the filter is expected to respond
with a success status and an empty list.
>
> On 12 Aug 2016, at 18:33, Stefan Beller wrote:
>
> On Wed, Aug 10, 2016 at 6:04 AM, wrote:
>> From: Lars Schneider
>>
>> Git's clean/smudge mechanism invokes an external filter process for every
>> single blob that is affected by a filter. If Git filt
> On 12 Aug 2016, at 17:48, Junio C Hamano wrote:
>
> Joseph Musser writes:
>
>> Looks like a simple typo.
>
> Unfortunately this does not reproduce to me (built from source on
> Ubuntu Linux).
I tried it with the latest released version on Windows and OSX (2.9.2)
and was not able to reprodu
> On 10 Aug 2016, at 15:43, Jeff King wrote:
>
> On Wed, Aug 10, 2016 at 03:04:01PM +0200, larsxschnei...@gmail.com wrote:
>
>> +int packet_write_gently_fmt(int fd, const char *fmt, ...)
>> +{
>> +static struct strbuf buf = STRBUF_INIT;
>> +va_list args;
>> +
>> +strbuf_reset(&buf);
601 - 700 of 1033 matches
Mail list logo