This is the revised patch taking the considerations about IO chunk size into
account. The series deletes more than it adds and fixes a bug. Nice.
Steffen Prohaska (2):
xread, xwrite: Limit size of IO, fixing IO of 2GB and more on Mac OS X
Revert "compate/clipped-write.c: large write(2) fails
Previously, filtering 2GB or more through an external filter (see test)
failed on Mac OS X 10.8.4 (12E55) for a 64-bit executable with:
error: read from external filter cat failed
error: cannot feed the input to external filter cat
error: cat died of signal 13
error: external filte
The previous commit introduced a size limit on IO chunks on all
platforms. The compat clipped_write() is not needed anymore.
This reverts commit 6c642a878688adf46b226903858b53e2d31ac5c3.
Signed-off-by: Steffen Prohaska
---
Makefile | 8
compat/clipped-write.c | 13 -
This may provide some clues for those who want to modify smart http
code as smart http is pretty much undocumented. Smart http "document"
so far is a few commit messages and the source code.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-fetch-pack.txt | 11 +++--
Documentati
On Mon, Aug 19, 2013 at 4:37 PM, Thomas Rast wrote:
> Hmm, IIUC that's actually not a bug or even a roughness; it's an
> artifact of how the :pattern:file syntax is defined. It takes the first
> _funcname line_ matching 'pattern', up to (but excluding) the next
> funcname line.
>
...
> Or is ther
When git submodule summary is run and there is a deleted submodule, there is an
warning from git rev-parse:
fatal: Not a git repository: '.vim/pathogen/.git'
Silence this warning, since it is fully expected that a deleted submodule will
not be a git repository.
Signed-off-by: brian m. carlson
It looks great to me.
Thanks,
--
Jharrod LaFon
OpenEye Scientific Software
On Aug 19, 2013, at 2:54 PM, Junio C Hamano wrote:
> Jharrod LaFon writes:
>
>> I will keep trying this until it's perfect, and I thank you for
>> the help. When I resubmit this, would you like me to include your
>>
Hi,
so today I compared the argument lists of the repack shell script with the
C rewrite passed on to the pack-objects command and fixed some corner
cases (-A -d --unpack-unreachable=%s should only pass
--unpack-unreachable=%s once to pack-objects)
Also I fixed some missing smaller options (--qu
This one seems real, although it's quite theoretical. It should only happen
in cases where the log-message contains "%1", the initial malloc passed and
reallocing two more bytes failed.
However, what's much more of a disaster: "pos" is used after the call to
realloc might have moved the memory!
I
- Original Message -
From: "Philip Oakley"
From: "Koch, Rick (Subcontractor)"
Sent: Monday, August 19, 2013 6:09 PM
I'm directing to this e-mail, as it seems to be the approved forum
for posting Git bugs. We ran CPPCheck against Git v.1.8.3.4
and found 24 high risk bugs. Please see the
On Mon, Aug 19, 2013 at 2:56 PM, Kyle J. McKay wrote:
>
> The fact that the entire file is read into memory when applying the filter
> does not seem like a good thing (see #7-#10 above).
Yeah, that's horrible. Its likely bad for performance too, because
even if you have enough memory, it blows ev
What's cooking in git.git (Aug 2013, #05; Mon, 19)
--
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
An extra release candidate -rc4 has been
On Aug 19, 2013, at 10:16, Junio C Hamano wrote:
Linus Torvalds writes:
So why isn't the patch much more straightforward? Like the attached
totally untested one that just limits the read/write size to 8MB
(which is totally arbitrary, but small enough to not have any latency
issues even on slo
From: "Koch, Rick (Subcontractor)"
Ran CPPCheck 1.5.6 on Windows-XP.
Hi Rick,
Thank you for the clarification.
Normal practice on the list is to use Reply All, so everyone can
participate in the discussion.
It looks like most of the reports are false positives. My bikeshedding
thought wou
On 08/19/2013 07:09 PM, Koch, Rick (Subcontractor) wrote:
> I'm directing to this e-mail, as it seems to be the approved forum for
> posting Git bugs. We ran CPPCheck against Git v.1.8.3.4 and found 24 high
> risk bugs. Please see the attachment xlsx.
>
> Is there a method to post to the Git c
On Fri, Aug 16, 2013 at 05:34:04PM +, Rasmus Villemoes wrote:
> The variable $prompting is weird. It is only read in one place (when
> deciding whether to prompt for a Message-ID to use in In-Reply-To),
> and it will be false unless we've taken the completely unrelated
> branch filling in @ini
Am 19.08.2013 10:13, schrieb Chris Packham:
> Hi Brian,
> On 19/08/13 05:31, brian m. carlson wrote:
>> When git submodule summary is run and there is a deleted submodule, there is
>> an
>> warning from git rev-parse:
>>
>> fatal: Not a git repository: '.vim/pathogen/.git'
>>
>> Silence this war
Am 17.08.2013 19:25, schrieb brian m. carlson:
> git status prints information for submodules, but it should ignore the status
> of
> those which have submodule..ignore set to all. Fix it so that it does
> properly ignore those which have that setting either in .git/config or in
> .gitmodules.
>
Am 17.08.2013 19:25, schrieb brian m. carlson:
> cmd_summary reads the output of git diff, but reads in the submodule path
> into a
> variable called name. Since this variable does not contain the name of the
> submodule, but the path, rename it to be clearer what data it actually holds.
>
> Sig
Jharrod LaFon writes:
> I will keep trying this until it's perfect, and I thank you for
> the help. When I resubmit this, would you like me to include your
> sign-off line as well?
If the one I attached at the end of the message you are responding
to looks fine to you, I'd just apply it without
On Mon, Aug 19, 2013 at 10:46 PM, Junio C Hamano wrote:
> Jeff King writes:
>> On Mon, Aug 19, 2013 at 09:03:21PM +0100, Philip Oakley wrote:
>> So out of the 4 entries I investigated, none of them looks like an
>> actual problem. But I'm not even sure I am looking at the right place;
>> these do
On Mon, Aug 19, 2013 at 11:56:17AM -0700, Junio C Hamano wrote:
> Jharrod LaFon writes:
>
> > Updated the patch and the patch submission.
> >
>
> Getting a lot warmer ;-).
Thanks, I agree with all of the stuff you said. The end result that you
included looks good to me.
-Peff
--
To unsubscrib
Jeff King writes:
> On Mon, Aug 19, 2013 at 09:03:21PM +0100, Philip Oakley wrote:
>
>> In case other readers don't have a .xlsx reader here is Rick's list
>> in plain text (may be white space damaged).
>>
>> I expect some will be false positives, and some will just be being
>> too cautious.
>>
On Aug 19, 2013, at 12:59, Junio C Hamano wrote:
Performance, Internal Implementation, etc.
* On Cygwin, we used to use our own lstat(2) emulation that is
allegedly faster than the platform one in codepaths where some of
the information it returns did not matter, but it started to bite
us
On Mon, Aug 19, 2013 at 09:03:21PM +0100, Philip Oakley wrote:
> In case other readers don't have a .xlsx reader here is Rick's list
> in plain text (may be white space damaged).
>
> I expect some will be false positives, and some will just be being
> too cautious.
>
> [...]
>
> description reso
From: "Koch, Rick (Subcontractor)"
Sent: Monday, August 19, 2013 6:09 PM
I'm directing to this e-mail, as it seems to be the approved forum
for posting Git bugs. We ran CPPCheck against Git v.1.8.3.4
and found 24 high risk bugs. Please see the attachment xlsx.
Is there a method to post to the
A release candidate Git v1.8.4-rc4 is now available for testing
at the usual places.
The only changes since -rc3 are reversion of two topics that
introduced regressions. Hopefully the final at the end of this week
and then we will start the next cycle, most likely to be for 1.8.5.
This is a bit
Jharrod LaFon writes:
> Updated the patch and the patch submission.
>
Getting a lot warmer ;-).
> -- >8 --
>
> Git segmentation faults if submodule path is empty.
If this is meant to replace the MUA's Subject: line, then please add
"Subject: " prefix, like the example at the end of this messa
On Mon, Aug 19, 2013 at 10:16 AM, Junio C Hamano wrote:
> Linus Torvalds writes:
>
> The same argument applies to xwrite(), but currently we explicitly
> catch EINTR and EAGAIN knowing that on sane systems these are the
> signs that we got interrupted.
>
> Do we catch EINVAL unconditionally in th
Thomas Rast writes:
> Whether the option value is a separate argument in argv, or directly
> stuck to the option.
>
> stuck: gitk -L:foo:main.c
> unstuck: gitk -L :foo:main.c
>
> Existing gitk chokes on 'gitk -S foo', but works with 'git -Sfoo'.
I somehow thought that we encourage the "stuck/s
Steffen Prohaska writes:
> I'm happy to rework it again towards your suggestion. I would also remove
> the compat wrapper for write(). But I got a bit tired. I'd appreciate if
> I received more indication whether a version without compat wrappers would
> be accepted.
I think it is a reasonabl
Linus Torvalds writes:
> I hate your patch for other reasons, though:
>
>> The problem for read() is addressed in a similar way by introducing
>> a wrapper function in compat that always reads less than 2GB.
>
> Why do you do that? We already _have_ wrapper functions for read(),
> namely xread().
I'm directing to this e-mail, as it seems to be the approved forum for posting
Git bugs. We ran CPPCheck against Git v.1.8.3.4 and found 24 high risk bugs.
Please see the attachment xlsx.
Is there a method to post to the Git community to allow the community to review
and debunk as faults posi
Johannes Sixt writes:
> Am 16.08.2013 00:36, schrieb Junio C Hamano:
>> Due to unfortunate regressions, two topics had to be reverted:
>>
>> * An attempted fix to "git stash save", to detect that going back
>> to the state of the HEAD needs to lose killed files, and/or
>> untracked file
On Aug 19, 2013, at 6:04 PM, Linus Torvalds
wrote:
> I hate your patch for other reasons, though:
>
>> The problem for read() is addressed in a similar way by introducing
>> a wrapper function in compat that always reads less than 2GB.
>
> Why do you do that? We already _have_ wrapper functio
Eric Sunshine writes:
>> +# Define NEEDS_CLIPPED_READ if your read(2) cannot read more than
>> +# INT_MAX bytes at once (e.g. MacOS X).
>> +#
>> # Define NEEDS_CLIPPED_WRITE if your write(2) cannot write more than
>> # INT_MAX bytes at once (e.g. MacOS X).
>
> Is it likely that we would see a p
Updated the patch and the patch submission.
-- >8 --
Git segmentation faults if submodule path is empty.
Git fails due to a segmentation fault if a submodule path is empty.
Here is an example .gitmodules that will cause a segmentation fault:
[submodule "foo-module"]
path
On Mon, Aug 19, 2013 at 8:41 AM, Steffen Prohaska wrote:
>
> The reason was that read() immediately returns with EINVAL if nbyte >=
> 2GB. According to POSIX [1], if the value of nbyte passed to read() is
> greater than SSIZE_MAX, the result is implementation-defined.
Yeah, the OS X filesystem l
Previously, filtering 2GB or more through an external filter (see test)
failed on Mac OS X 10.8.4 (12E55) for a 64-bit executable with:
error: read from external filter cat failed
error: cannot feed the input to external filter cat
error: cat died of signal 13
error: external filte
On 2013-08-19 08.38, Steffen Prohaska wrote:
[snip]
> diff --git a/builtin/var.c b/builtin/var.c
> index aedbb53..e59f5ba 100644
> --- a/builtin/var.c
> +++ b/builtin/var.c
> @@ -38,6 +38,7 @@ static struct git_var git_vars[] = {
> { "", NULL },
> };
>
> +#undef read
This is techically ri
On Mon, Aug 19, 2013 at 10:13 AM, Francis Moreau wrote:
> Hello,
>
> Is it possible to keep submodules notes in the super project ?
Not easily. I guess it depends on what you want to use the notes for.
In order for notes to be generally useful (i.e. show up in logs,
surviving a notes prune, etc.
On Mon, Aug 19, 2013 at 4:21 AM, Steffen Prohaska wrote:
> Previously, filtering 2GB or more through an external filter (see test)
> failed on Mac OS X 10.8.4 (12E55) for a 64-bit executable with:
>
> error: read from external filter cat failed
> error: cannot feed the input to external fi
I have a project for you in the tune of One Hundred & Five Million EUR,Please
reply for specifics.
--
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://vger.kernel.org/majordomo-info.html
Am 19.08.2013 10:25, schrieb Stefan Beller:
On 08/19/2013 10:20 AM, Johannes Sixt wrote:
Am 19.08.2013 08:38, schrieb Steffen Prohaska:
+test_expect_success EXPENSIVE 'filter large file' '
+git config filter.largefile.smudge cat &&
+git config filter.largefile.clean cat &&
+for i in
Nazri Ramliy writes:
> On Sun, Aug 18, 2013 at 6:33 PM, Zhan Jianyu wrote:
>> Such a requirement came into my mind when I am tracking a gloomy C
>> struct , with lengthy list of elements which are either elaborated or
>> opaque. So I use git blame to track it down and found that its
>> origina
On Aug 19, 2013, at 10:20 AM, Johannes Sixt wrote:
> Am 19.08.2013 08:38, schrieb Steffen Prohaska:
>> +test_expect_success EXPENSIVE 'filter large file' '
>> +git config filter.largefile.smudge cat &&
>> +git config filter.largefile.clean cat &&
>> +for i in $(test_seq 1 2048); do p
Am 19.08.2013 08:38, schrieb Steffen Prohaska:
Note that 'git add' exits with 0 even if it prints filtering errors to
stderr. The test, therefore, checks stderr. 'git add' should probably
be changed (sometime in another commit) to exit with nonzero if
filtering fails. The test could then be ch
On 08/19/2013 10:20 AM, Johannes Sixt wrote:
> Am 19.08.2013 08:38, schrieb Steffen Prohaska:
>> +test_expect_success EXPENSIVE 'filter large file' '
>> +git config filter.largefile.smudge cat &&
>> +git config filter.largefile.clean cat &&
>> +for i in $(test_seq 1 2048); do printf "%1
Paul Mackerras writes:
> Hi Thomas,
>
> On Wed, Jul 31, 2013 at 03:17:41PM +0200, Thomas Rast wrote:
>> Jens Lehmann writes:
>>
>> > Am 29.07.2013 21:37, schrieb Thomas Rast:
>> >> Thomas Rast writes:
>> >>
>> >>> Thomas Rast writes:
>> >>>
>> Now that git log -L has hit master, I figur
Previously, filtering 2GB or more through an external filter (see test)
failed on Mac OS X 10.8.4 (12E55) for a 64-bit executable with:
error: read from external filter cat failed
error: cannot feed the input to external filter cat
error: cat died of signal 13
error: external filte
Am 19.08.2013 08:38, schrieb Steffen Prohaska:
+test_expect_success EXPENSIVE 'filter large file' '
+ git config filter.largefile.smudge cat &&
+ git config filter.largefile.clean cat &&
+ for i in $(test_seq 1 2048); do printf "%1048576d" 1; done >2GB &&
Shouldn't you count t
On Aug 19, 2013, at 9:54 AM, John Keeping wrote:
> You've created compat/clipped-read.c, but...
>
>> Makefile | 8
>> builtin/var.c | 1 +
>> config.mak.uname | 1 +
>> git-compat-util.h | 5 +
>> streaming.c | 1 +
>> t/t0021-conversion.sh |
Hello,
Is it possible to keep submodules notes in the super project ?
Thanks
--
Francis
--
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://vger.kernel.org/majordomo-info.html
Hi Brian,
On 19/08/13 05:31, brian m. carlson wrote:
> When git submodule summary is run and there is a deleted submodule, there is
> an
> warning from git rev-parse:
>
> fatal: Not a git repository: '.vim/pathogen/.git'
>
> Silence this warning, since it is fully expected that a deleted submo
On Mon, Aug 19, 2013 at 08:38:20AM +0200, Steffen Prohaska wrote:
> diff --git a/Makefile b/Makefile
> index 3588ca1..0f69e24 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -69,6 +69,9 @@ all::
> # Define NO_MSGFMT_EXTENDED_OPTIONS if your implementation of msgfmt
> # doesn't support GNU extension
55 matches
Mail list logo
