On 03 Jan 2018, at 20:15, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> May be.
>> Originally utf8.c was about encoding and all kind of UTF-8 related stuff.
>> Especially it didn't know anything about strbuf.
>> I don't know why strbuf.h and other functions had been added here,
>>
> On 04 Jan 2018, at 21:13, Thomas Gummerer wrote:
>
> On 12/18, Lars Schneider wrote:
>>
>>> On 17 Dec 2017, at 23:51, Thomas Gummerer wrote:
>>>
>>> Split index mode only has a few dedicated tests, but as the index is
>>> involved in nearl
F_FALSE.
>
> Turn the whole call chain to use an integer with single bits, which
> can be extended in the next commits:
> - The global configuration variable safe_crlf is now conv_flags_eol.
> - The parameter checksafe is renamed into conv_flags.
>
> Helped-By: Lars Schne
From: Lars Schneider
Hi,
Patches 1-5 and 6 are helper functions and preparation.
Patch 6 is the actual change.
I am still torn between "checkout-encoding" and "working-tree-encoding"
as attribute name. I am happy to hear arguments for/against one or the
other.
Change
n enum is not ideal. Let's use a integer bit pattern instead and rename
the parameter to conv_flags to make it more generically usable. This
allows us to extend the bit pattern in a subsequent commit.
Helped-By: Lars Schneider
Signed-off-by: Torsten Bögershausen
Signed-off-by: Lars Schneider
From: Lars Schneider
Since 3733e69464 (use xmallocz to avoid size arithmetic, 2016-02-22) we
allocate the buffer for the lower case string with xmallocz(). This
already ensures a NUL at the end of the allocated buffer.
Remove the unnecessary assignment.
Signed-off-by: Lars Schneider
From: Lars Schneider
Git recognizes files encoded with ASCII or one of its supersets (e.g.
UTF-8 or ISO-8859-1) as text files. All other encodings are usually
interpreted as binary and consequently built-in Git text processing
tools (e.g. 'git diff') as well as most Git web front e
From: Lars Schneider
Whenever a data stream is declared to be UTF-16BE, UTF-16LE, UTF-32BE
or UTF-32LE a BOM must not be used [1]. The function returns true if
this is the case.
This function is used in a subsequent commit.
[1] http://unicode.org/faq/utf_bom.html#bom10
Signed-off-by: Lars
From: Lars Schneider
Create a copy of an existing string and make all characters upper case.
Similar xstrdup_tolower().
This function is used in a subsequent commit.
Signed-off-by: Lars Schneider
---
strbuf.c | 12
strbuf.h | 1 +
2 files changed, 13 insertions(+)
diff --git a
From: Lars Schneider
Add the GIT_TRACE_CHECKOUT_ENCODING environment variable to enable
tracing for content that is reencoded with the checkout-encoding
attribute.
Signed-off-by: Lars Schneider
---
convert.c| 28
t/t0028-checkout-encoding.sh
From: Lars Schneider
If the endianness is not defined in the encoding name, then let's
be strict and require a BOM to avoid any encoding confusion. The
has_missing_utf_bom() function returns true if a required BOM is
missing.
The Unicode standard instructs to assume big-endian if there
> On 06 Jan 2018, at 00:22, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> On 31 Dec 2017, at 09:05, tbo...@web.de wrote:
>>>
>>> From: Torsten Bögershausen
>>>
>>> When calling convert_to_git(), the checksafe parame
> On 07 Jan 2018, at 10:38, Torsten Bögershausen wrote:
>
> On Sat, Jan 06, 2018 at 01:48:01AM +0100, lars.schnei...@autodesk.com wrote:
>> From: Lars Schneider
>>
>> Hi,
>>
>> Patches 1-5 and 6 are helper functions and preparation.
>> Patch 6
> On 08 Jan 2018, at 23:07, Junio C Hamano wrote:
>
> SZEDER Gábor writes:
>
>> The reason why Travis CI does it this way and why it's a better
>> approach than ours lies in how unsuccessful build jobs are
>> categorized. ...
>> ...
>> This makes it easier, both for humans looking at the Trav
> On 08 Jan 2018, at 22:28, Junio C Hamano wrote:
>
> lars.schnei...@autodesk.com writes:
>
>> diff --git a/sha1_file.c b/sha1_file.c
>> index afe4b90f6e..dcb02e9ffd 100644
>> --- a/sha1_file.c
>> +++ b/sha1_file.c
>> @@ -75,14 +75,14 @@ static struct cached_object *find_cached_object(const
>>
> On 14 Dec 2017, at 00:00, Junio C Hamano wrote:
>
> Here are the topics that have been cooking. Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'. The ones marked with '.' do not appear in any of
> the integration branches, but I
> On 18 Jan 2018, at 23:40, SZEDER Gábor wrote:
>
> On Thu, Jan 18, 2018 at 10:40 PM, René Scharfe wrote:
>> Am 16.01.2018 um 18:11 schrieb SZEDER Gábor:
>>> Unfortunately, most of the changes coming from 'strbuf.cocci' don't
>>> make any sense, they appear to be the mis-application of the "use
From: Lars Schneider
Hi,
Patches 1-4 and 6 are preparation and helper functions.
Patch 5 is the actual change.
This series depends on Torsten's "convert_to_git(): safe_crlf/checksafe
becomes int conv_flags" patch:
https://public-inbox.org/git/20180113224931.27031-1-tbo...@w
From: Lars Schneider
Since 3733e69464 (use xmallocz to avoid size arithmetic, 2016-02-22) we
allocate the buffer for the lower case string with xmallocz(). This
already ensures a NUL at the end of the allocated buffer.
Remove the unnecessary assignment.
Signed-off-by: Lars Schneider
From: Lars Schneider
Whenever a data stream is declared to be UTF-16BE, UTF-16LE, UTF-32BE
or UTF-32LE a BOM must not be used [1]. The function returns true if
this is the case.
This function is used in a subsequent commit.
[1] http://unicode.org/faq/utf_bom.html#bom10
Signed-off-by: Lars
From: Lars Schneider
Git recognizes files encoded with ASCII or one of its supersets (e.g.
UTF-8 or ISO-8859-1) as text files. All other encodings are usually
interpreted as binary and consequently built-in Git text processing
tools (e.g. 'git diff') as well as most Git web front e
From: Lars Schneider
Create a copy of an existing string and make all characters upper case.
Similar xstrdup_tolower().
This function is used in a subsequent commit.
Signed-off-by: Lars Schneider
---
strbuf.c | 12
strbuf.h | 1 +
2 files changed, 13 insertions(+)
diff --git a
From: Lars Schneider
Add the GIT_TRACE_CHECKOUT_ENCODING environment variable to enable
tracing for content that is reencoded with the 'working-tree-encoding'
attribute. This is useful to debug encoding issues.
Signed-off-by: Lars Schneider
---
convert.c
From: Lars Schneider
If the endianness is not defined in the encoding name, then let's
be strict and require a BOM to avoid any encoding confusion. The
has_missing_utf_bom() function returns true if a required BOM is
missing.
The Unicode standard instructs to assume big-endian if there
> On 21 Jan 2018, at 15:22, Simon Ruderich wrote:
>
> On Sat, Jan 20, 2018 at 04:24:17PM +0100, lars.schnei...@autodesk.com wrote:
>> +static struct encoding *git_path_check_encoding(struct attr_check_item
>> *check)
>> +{
>> +const char *value = check->value;
>> +struct encoding *enc;
From: Lars Schneider
Hi Junio,
this attached patch addresses Simon's review comments.
Can you squash the patch if you apply "[PATCH v4 5/6] convert: add
'working-tree-encoding' attribute"?
https://public-inbox.org/git/20180120152418.52859-6-lars.schnei...@au
From: Lars Schneider
Hi Junio,
I overlooked a typo pointed out in Simon's review. Here is a new patch
for squashing. Sorry for the trouble!
@Eric: Thanks for spotting this!
Cheers,
Lars
convert.c| 8 ++--
t/t0028-working-tree-encoding.sh | 2 ++
2 files ch
> On 22 Jan 2018, at 19:27, SZEDER Gábor wrote:
>
>
> On Thu, Jan 18, 2018 at 1:47 PM, Duy Nguyen wrote:
>> On Thu, Jan 18, 2018 at 6:36 PM, SZEDER Gábor wrote:
>>> This series, queued as 'nd/shared-index-fix', makes the 32 bit Linux
>>> build job fail on Travis CI. Unfortunately, all it can
Hi Peff,
I would like to register to the contributor summit :-)
---
As I am writing you, I thought I could ask you a question:
"git verify-pack" tells me the "size-in-packfile" which is
kind of the "real" size of a file in a Git repo. Are you
aware of a way to get this number via the GitHub AP
> On 29 Jan 2018, at 21:19, tbo...@web.de wrote:
>
> From: Torsten Bögershausen
>
> UTF-16 encoded files are treated as "binary" by Git, and no CRLF
> conversion is done.
> When the UTF-16 encoded files are converted into UF-8 using the new
s/UF-8/UTF-8/
> "working-tree-encoding", the CRLF ar
> On 30 Jan 2018, at 15:40, Torsten Bögershausen wrote:
>
> On Tue, Jan 30, 2018 at 12:23:47PM +0100, Lars Schneider wrote:
>>
>>> On 29 Jan 2018, at 21:19, tbo...@web.de wrote:
>>>
>>> From: Torsten Bögershausen
>>>
>>> UTF-
> On 30 Jan 2018, at 21:05, Junio C Hamano wrote:
>
> tbo...@web.de writes:
>
>> +if ((conv_flags & CONV_WRITE_OBJECT) && !strcmp(enc->name,
>> "SHIFT-JIS")) {
>> +char *re_src;
>> +int re_src_len;
>
> I think it is a bad idea to
>
> (1) not check without CONV_WR
> On 30 Jan 2018, at 20:15, Junio C Hamano wrote:
>
> tbo...@web.de writes:
>
>> From: Lars Schneider
>>
>> If the endianness is not defined in the encoding name, then let's
>> be strict and require a BOM to avoid any encoding confusion. The
>>
> On 30 Jan 2018, at 22:56, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> On 30 Jan 2018, at 21:05, Junio C Hamano wrote:
>>>
>>> tbo...@web.de writes:
>>>
>>>> + if ((conv_flags & CONV_WRITE_OBJECT) &&am
> On 31 Jan 2018, at 18:28, Torsten Bögershausen wrote:
>
> []
>>> That is a good one.
>>> If you ever plan a re-roll (I don't at the moment) the *.proj extemsion
>>> make much more sense in Documentation/gitattributes that *.tx
>>> There no text files encoded in UTF-16 wich are called xxx.txt,
?
Cheers,
Lars
On 05 Aug 2015, at 00:06, Luke Diamand wrote:
> On 02/08/15 16:15, larsxschnei...@gmail.com wrote:
>> From: Lars Schneider
>>
>> Hi,
>>
>> I want to propose this patch as it helped us to migrate a big source code
>> base
>> successfully fr
Thanks for your feedback! See my answers below.
On 20 Aug 2015, at 06:59, Torsten Bögershausen wrote:
> Some nit-picking below:
> On 08/19/2015 10:04 PM, larsxschnei...@gmail.com wrote:
>> From: Lars Schneider
>>
>> PROBLEM:
>> We run P4 servers on Linux and
amano wrote:
> Lars Schneider writes:
>
>>>> + find . | grep TWO/file1.txt &&
>>>> + find . | grep TWO/File2.txt &&
>>>> + find . | grep TWO/file3.txt &&
>>> Not sure about the find | grep here e
On 21 Aug 2015, at 20:01, Junio C Hamano wrote:
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> PROBLEM:
>> We run P4 servers on Linux and P4 clients on Windows. For an unknown
>> reason the file path for a number of files in P4 does
On 24 Aug 2015, at 08:33, Junio C Hamano wrote:
> Lars Schneider writes:
>
>>> - Have you checked "git log" on our history and notice how nobody
>>> says "PROBLEM:" and "SOLUTION:" in capital letters? Don't try to
>>> be or
pass a parameter switch to git-p4.
> Additionally, could you update your patch to add some words to
> Documentation/git-p4.txt please?
I will do that!
> On 21 August 2015 at 18:19, wrote:
>> From: Lars Schneider
>>
>> PROBLEM:
>> We run P4 servers on Li
>
>
>
>>
>> While I was working on the examples for this email reply I realized that the
>> problem is only present for paths given in a client-spec. I added a test
>> case to prove that. That means I don’t need to request *all* paths. I
>> *think* it is sufficient to request the paths ment
On 25 Aug 2015, at 08:54, Luke Diamand wrote:
> On 24/08/15 22:30, larsxschnei...@gmail.com wrote:
>> From: Lars Schneider
>>
>> Thanks to Luke Diamand I realized the core problem and propose here a
>> substiantially simpler fix to my PATCH v4.
>>
>&
On 25 Aug 2015, at 10:33, Torsten Bögershausen wrote:
> On 08/25/2015 08:54 AM, Luke Diamand wrote:
>> On 24/08/15 22:30, larsxschnei...@gmail.com wrote:
>>> From: Lars Schneider
>>>
>>> Thanks to Luke Diamand I realized the core problem and propose here a
On 25 Aug 2015, at 13:57, Luke Diamand wrote:
> On 25/08/15 11:30, larsxschnei...@gmail.com wrote:
>
>> Unfortunately the command line option is not sufficient as the resulting
>> paths are still messed up. I added the switch but it looks like as
>> core.ignorecase does some additional magic o
On 26 Aug 2015, at 22:05, Junio C Hamano wrote:
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> We run P4 servers on Linux and P4 clients on Windows. For an unknown
>> reason the file path for a number of files in P4 does not match the
>
or do you want to support Python 2/3 in
parallel? I would prefer the former…
- Lars
On 30 Aug 2015, at 10:49, Luke Diamand wrote:
> On 28 August 2015 at 13:24, wrote:
>> From: Lars Schneider
>>
>> I am migrating huge Perforce repositories including history to Git.
On 01 Sep 2015, at 06:37, Torsten Bögershausen wrote:
> On 01/09/15 00:10, larsxschnei...@gmail.com wrote:
>> From: Lars Schneider
>>
>> Signed-off-by: Lars Schneider
>> ---
>> Documentation/git-p4.txt| 5 +
>> git-p4.py
On 01 Sep 2015, at 01:13, Junio C Hamano wrote:
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>
> Here is a space for you to describe what it does and why it is a
> good idea to have it.
How about this:
Perforce keeps the encoding of a path as
On 01 Sep 2015, at 16:35, Torsten Bögershausen wrote:
> On 2015-09-01 14.47, Lars Schneider wrote:
>>>> +test_expect_success 'Create a repo containing iso8859-1 encoded paths' '
>>>>>> +cd "$cli" &&
>>>
On 01 Sep 2015, at 19:35, Junio C Hamano wrote:
> Lars Schneider writes:
>
>> On 01 Sep 2015, at 01:13, Junio C Hamano wrote:
>>
>>> larsxschnei...@gmail.com writes:
>>>
>>>> From: Lars Schneider
>>>>
>>>
>>>
On 30 Aug 2015, at 18:36, Luke Diamand wrote:
> On 30 August 2015 at 11:18, Lars Schneider wrote:
>> Thanks for your feedback!
>>
>> I like the “handle big files” plugin kind of idea. However, I wonder if it
>> makes sense to put more and more stuff into g
On 03 Sep 2015, at 15:04, Eric Sunshine wrote:
> On Thu, Sep 3, 2015 at 5:34 AM, wrote:
>> From: Lars Schneider
>>
>> Signed-off-by: Lars Schneider
>> ---
>> diff --git a/t/t9821-git-p4-path-variations.sh
>> b/t/t9821-git-p4-path-variations.sh
>
On 03 Sep 2015, at 10:26, Remi Galan Alfonso
wrote:
> Hi Lars,
>
> Lars Schneider writes:
>
>> +test_expect_success 'Clone repo containing iso8859-1 encoded paths with
>> git-p4.pathEncoding' '
>> +
>> +test_when_finished cleanu
On 03 Sep 2015, at 19:03, Junio C Hamano wrote:
> larsxschnei...@gmail.com writes:
>
>> +test_expect_success 'Clone repo containing iso8859-1 encoded paths without
>> git-p4.pathEncoding' '
>> +git p4 clone --destination="$git" //depot &&
>> +test_when_finished cleanup_git &&
>> +(
On 03 Sep 2015, at 21:55, Luke Diamand wrote:
> On 03/09/15 17:35, larsxschnei...@gmail.com wrote:
>> From: Lars Schneider
>>
>
> I think this commit may need some explanation!
The functions “gitConfig” and “gitConfigBool” are almost identical. Make
“gitConfig” more
On 03 Sep 2015, at 21:57, Luke Diamand wrote:
> On 03/09/15 17:35, larsxschnei...@gmail.com wrote:
>> From: Lars Schneider
>>
>
> Explanation?
Add a git config reader for integer variables. Please note that the git config
implementation automatically supports k, m
On 03 Sep 2015, at 22:03, Luke Diamand wrote:
> On 03/09/15 17:35, larsxschnei...@gmail.com wrote:
>> From: Lars Schneider
>>
>> Perforce repositories can contain large (binary) files. Migrating these
>> repositories to Git generates very large local clones. Exter
On 03 Sep 2015, at 22:18, Junio C Hamano wrote:
> Lars Schneider writes:
>
>> On 03 Sep 2015, at 21:55, Luke Diamand wrote:
>>
>>> On 03/09/15 17:35, larsxschnei...@gmail.com wrote:
>>>> From: Lars Schneider
>>>>
>>>
>>>
On 03 Sep 2015, at 23:31, Junio C Hamano wrote:
> Lars Schneider writes:
>
>> In case I agree with a reviewer. What is the more appropriate action?
>> A response like the one above or a new role that includes the change
>> right away? I don’t want to spam the list w
I wanted to play with the patch and apply it to my source but the process is
really complicated for me. I wonder if you can give me a few recommendations
how to work efficiently with email patches. I don’t want to start a flame-war
about what email client is “right", I am just curious how you wo
On 09 Sep 2015, at 18:00, Junio C Hamano wrote:
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> If read_pipe crashes then the caller can inspect the error and handle
>> it appropriately.
>>
>> Signed-off-by: Lars Schneider
>
On 09 Sep 2015, at 19:20, Junio C Hamano wrote:
> larsxschnei...@gmail.com writes:
>
>> @@ -2226,17 +2355,16 @@ class P4Sync(Command, P4UserMap):
>> text = regexp.sub(r'$\1$', text)
>> contents = [ text ]
>>
>> -self.gitStream.write("M %s inline %s\n" % (git_mod
> On 10 Jul 2016, at 17:10, Joey Hess wrote:
>
> larsxschnei...@gmail.com wrote:
>> (2) Joey's topic, which is the base for my patch, looks stalled for more than
>> 2 weeks:
>> http://thread.gmane.org/gmane.comp.version-control.git/297994/focus=298006
>> I would be happy to address Junio's comme
> On 12 Jul 2016, at 00:45, Joey Hess wrote:
>
> This adds new smudgeToFile and cleanFromFile filter commands,
> which are similar to smudge and clean but allow direct access to files on
> disk.
>
> This interface can be much more efficient when operating on large files,
> because the whole fil
On 13 Jul 2016, at 22:43, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> It is somewhat disturbing that nobody seems to be regularly building
>> on 32-bit platforms these days, which is the only reason I can think
>> of why this was never reported until it hit a maintenance track.
>> This
> On 15 Jul 2016, at 08:46, Christian Couder wrote:
>
> [...]
>
> The current topics/work I can think of are:
>
> - the ref backend work by Michael based on Ronnie Sahlberg's and others' work,
> - the smudge/clean filters work by Joey and Lars,
> - the watchman/index helper work by David, Duy
> On 13 Jul 2016, at 18:56, Junio C Hamano wrote:
>
...
>
> * ew/http-walker (2016-07-12) 3 commits
> - http-walker: reduce O(n) ops with doubly-linked list
> - http: avoid disconnecting on 404s for loose objects
> - http-walker: remove unused parameter from fetch_object
>
> Optimize dumb http
> On 16 Jul 2016, at 23:04, Eric Wong wrote:
>
> Lars Schneider wrote:
>>> On 13 Jul 2016, at 18:56, Junio C Hamano wrote:
>>> * ew/http-walker (2016-07-12) 3 commits
>>> - http-walker: reduce O(n) ops with doubly-linked list
>>> - http:
> On 17 Jul 2016, at 02:25, Eric Wong wrote:
>
> Eric Wong wrote:
>> Lars Schneider wrote:
>>> It looks like as if this topic breaks the OS X build because
>>> it defines LIST_HEAD. LIST_HEAD is already defined in
>>> /usr/include/sys/queue.h.
Hi,
a long time ago in aa4ed4 Junio introduced the external filter driver
definition. Since that time we fork the Git process and then we fork again to
run the external filter. This is probably a super stupid question with an
obvious answer... but can anyone help me to understand the code and e
On 19 Jul 2016, at 20:53, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> The key benefit of this arrangement is the above can be done without
>> having to do poll() to flip between reading and writing that is
>> needed to avoid deadlocking, which kept the code simpler. A later
>> convers
Hi,
some time ago Michael wrote in a blog post [1]:
"It's not recommended to use git worktree with a repository that contains
submodules."
Plus "Documentation/git-worktree.txt" states:
"Multiple checkout in general is still experimental, and the support
for submodules is incomplete. It is NOT re
On 19 Jul 2016, at 23:33, Junio C Hamano wrote:
> Lars Schneider writes:
>
>> Git writes --> 4 byte filename length
>> Git writes --> filename string
>
> Why limit to 32GB? Perhaps NUL termination is more appropriate
> here?
OK, I will use NUL terminati
On 20 Jul 2016, at 00:54, Junio C Hamano wrote:
>
> [New Topics]
>
> ...
>
> * jk/push-scrub-url (2016-07-14) 1 commit
> (merged to 'next' on 2016-07-19 at 6ada3f1)
> + push: anonymize URL in status output
>
> "git fetch http://user:pass@host/repo..."; scrubbed the userinfo
> part, but "git
> On 20 Jul 2016, at 10:59, Jakub Narębski wrote:
>
> W dniu 2016-07-19 o 23:33, Junio C Hamano pisze:
>> Lars Schneider writes:
>>
>>>> Git writes --> 4 byte filename length
>>>> Git writes --> filename string
>>
>> Why limi
On 20 Jul 2016, at 13:32, Jeff King wrote:
> On Wed, Jul 20, 2016 at 10:20:33AM +0200, Lars Schneider wrote:
>
>>> * jk/push-scrub-url (2016-07-14) 1 commit
>>> (merged to 'next' on 2016-07-19 at 6ada3f1)
>>> + push: anonymize URL in status output
&
On 22 Jul 2016, at 23:39, Junio C Hamano wrote:
> larsxschnei...@gmail.com writes:
>
>> The first two patches are cleanup patches which are not really necessary
>> for the feature.
>
> These two looked trivially good.
Thanks!
> I think I can agree with what 3/3 wants to do in principle, but
On 23 Jul 2016, at 00:32, Torsten Bögershausen wrote:
> On 07/22/2016 05:49 PM, larsxschnei...@gmail.com wrote:
>> From: Lars Schneider
>>
>> [...]
>>
>> 1. Git starts the filter on first usage and expects a welcome message
>> with protocol version numb
On 23 Jul 2016, at 01:19, Ramsay Jones wrote:
> On 22/07/16 16:49, larsxschnei...@gmail.com 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 fi
On 23 Jul 2016, at 02:11, Jakub Narębski wrote:
> W dniu 2016-07-22 o 17:49, larsxschnei...@gmail.com pisze:
>> From: Lars Schneider
>
> Nb. this line is only needed if you want author name and/or date
> different from the email sender, or if you have sender line misconfigur
On 23 Jul 2016, at 10:14, Eric Wong wrote:
> larsxschnei...@gmail.com wrote:
>> Please note that the protocol filters do not support stream processing
>> with this implemenatation because the filter needs to know the length of
>> the result in advance. A protocol version 2 could address this in
On 24 Jul 2016, at 22:14, Jakub Narębski wrote:
> W dniu 2016-07-24 o 20:36, Lars Schneider pisze:
>> On 23 Jul 2016, at 02:11, Jakub Narębski wrote:
>>> W dniu 2016-07-22 o 17:49, larsxschnei...@gmail.com pisze:
>>>> From: Lars Schneider
>>>
>&
On 24 Jul 2016, at 23:30, Jakub Narębski wrote:
> W dniu 2016-07-24 o 22:14, Jakub Narębski pisze:
>> W dniu 2016-07-24 o 20:36, Lars Schneider pisze:
>
>>> I agree that the name is not ideal. "UseProtocol" as it is would be a
>>> boolean.
>&g
On 25 Jul 2016, at 00:36, Ramsay Jones wrote:
> On 24/07/16 18:16, Lars Schneider wrote:
>>
>> On 23 Jul 2016, at 01:19, Ramsay Jones wrote:
>>
>>> On 22/07/16 16:49, larsxschnei...@gmail.com wrote:
>>>> From: Lars Schneider
>>>>
>&g
On 25 Jul 2016, at 01:22, Jakub Narębski wrote:
> W dniu 2016-07-25 o 00:36, Ramsay Jones pisze:
>> On 24/07/16 18:16, Lars Schneider wrote:
>>> On 23 Jul 2016, at 01:19, Ramsay Jones wrote:
>>>> On 22/07/16 16:49, larsxschnei...@gmail.com wrote:
> [...]
On 26 Jul 2016, at 00:50, Junio C Hamano wrote:
> [...]
>
>
> * ew/git-svn-http-tests (2016-07-25) 2 commits
> - git svn: migrate tests to use lib-httpd
> - t/t91*: do not say how to avoid the tests
>
> Reuse the lib-httpd test infrastructure when testing the subversion
> integration that int
> On 27 Jul 2016, at 02:20, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> `set_packet_header` converts an integer to a 4 byte hex string. Make
>> this function publicly available so that other parts of Git can e
> On 27 Jul 2016, at 15:32, Jeff King wrote:
>
> On Wed, Jul 27, 2016 at 04:35:32AM +0200, Torsten Bögershausen wrote:
>
>>> + mkdir -p generated-test-data &&
>>> + for i in $(test_seq 1 $T0021_LARGE_FILE_SIZE)
>>> + do
>>> + # Generate 1MB of empty data and 100 bytes of random
> On 27 Jul 2016, at 03:32, Jeff King wrote:
>
> On Wed, Jul 27, 2016 at 02:06:05AM +0200, larsxschnei...@gmail.com wrote:
>
>> +static off_t multi_packet_read(struct strbuf *sb, const int fd, const
>> size_t size)
>> +{
>> +off_t bytes_read;
>> +off_t total_bytes_read = 0;
>
> I have
> On 27 Jul 2016, at 21:08, Jakub Narębski wrote:
>
> W dniu 2016-07-27 o 02:06, larsxschnei...@gmail.com pisze:
>> From: Lars Schneider
>>
>> Hi,
>>
>> thanks a lot for the extensive reviews. I tried to address all mentioned
>> concerns and summ
> On 27 Jul 2016, at 22:01, Jakub Narębski wrote:
>
> W dniu 2016-07-27 o 02:06, larsxschnei...@gmail.com pisze:
>
>> Git filter with spaces (e.g. `filter.sh foo`) are hard to read in
>> error messages. Quote them to improve the readability.
>
> This is not something very important, but the ab
Hi,
gmane is down and I wonder if there are alternatives to
find a message based on the message ID in the Git
mailing list archive?
Thanks,
Lars
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://
> On 27 Jul 2016, at 20:11, Jeff King wrote:
>
> On Wed, Jul 27, 2016 at 07:31:26PM +0200, Lars Schneider wrote:
>
>>>> + strbuf_grow(sb, size + 1); // we need one extra byte for the
>>>> packet flush
>>>
>>> What happens if size i
> On 28 Jul 2016, at 01:31, Jakub Narębski wrote:
>
> W dniu 2016-07-27 o 02:06, larsxschnei...@gmail.com pisze:
>> From: Lars Schneider
>>
>> Git's clean/smudge mechanism invokes an external filter process for every
>> single blob that is affected by a
> On 29 Jul 2016, at 09:40, Jakub Narębski wrote:
>
> W dniu 2016-07-28 o 15:29, Jeff King pisze:
>> On Thu, Jul 28, 2016 at 09:16:18AM +0200, Lars Schneider wrote:
>>
>>> But Peff ($gmane/299902), Duy, and Eric, seemed to prefer the pkt-line
>>> solu
> On 27 Jul 2016, at 11:41, Eric Wong wrote:
>
> larsxschnei...@gmail.com wrote:
>> +static off_t multi_packet_read(struct strbuf *sb, const int fd, const
>> size_t size)
>
> I'm no expert in C, but this might be const-correctness taken
> too far. I think basing this on the read(2) prototype
> On 29 Jul 2016, at 13:24, Jakub Narębski wrote:
>
> W dniu 2016-07-29 o 12:38, Lars Schneider pisze:
>> On 27 Jul 2016, at 11:41, Eric Wong wrote:
>>> larsxschnei...@gmail.com wrote:
>
>>>> +static off_t multi_packet_read(struct strbuf *sb
> On 29 Jul 2016, at 17:57, Jeff King wrote:
>
> On Fri, Jul 29, 2016 at 10:14:17AM +0200, Lars Schneider wrote:
>
>> My current implementation supports only two cases. Either the filter
>> knows the size and sends it back. Or the filter doesn't know the size
>
> On 29 Jul 2016, at 18:50, Jeff King wrote:
>
> On Fri, Jul 29, 2016 at 06:20:51PM +0200, Lars Schneider wrote:
>
>>>> That being said a "fail" response is a very good idea! This allows
>>>> the filter to communicate to git that a non required
501 - 600 of 1011 matches
Mail list logo
