Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
Documentation/git-interpret-trailers.txt | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-interpret-trailers.txt
b/Documentation/git-interpret-trailers.txt
index d6d9231..816dd65 100644
This way people who always want trimed trailers
don't need to specify it on the command line.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
builtin/interpret-trailers.c | 2 +-
trailer.c| 13 ++---
trailer.h| 2 +-
3 files changed,
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
t/t7513-interpret-trailers.sh | 72 +++
1 file changed, 72 insertions(+)
diff --git a/t/t7513-interpret-trailers.sh b/t/t7513-interpret-trailers.sh
index bd0ab46..066d00b 100755
---
Joachim Schmitz jojo at schmitz-digital.de writes:
Torsten Bögershausen tboegi at web.de writes:
On 2015-02-07 17.45, Joachim Schmitz wrote:
snip
b) never ever should read() be asked to read more than SSIZE_MAX, this
should be true for every platform on the planet? You may want to
On 2015-02-07 12:30PM Torsten Bögershausen wrote:
On 2015-02-07 17.45, Joachim Schmitz wrote:
Hi there
While investigating the problem with hung git-upload-pack we think to
have found a bug in wrapper.c:
#define MAX_IO_SIZE (8*1024*1024)
This is then used in xread() to split read()s
On 2015-02-07 13:07PM Randall S. Becker wrote:
On 2015-02-07 12:30PM Torsten Bögershausen wrote:
On 2015-02-07 17.45, Joachim Schmitz wrote:
Hi there
While investigating the problem with hung git-upload-pack we think to
have found a bug in wrapper.c:
#define MAX_IO_SIZE (8*1024*1024)
Randall S. Becker rsbecker at nexbridge.com writes:
On 2015-02-07 13:07PM Randall S. Becker wrote:
On 2015-02-07 12:30PM Torsten Bögershausen wrote:
On 2015-02-07 17.45, Joachim Schmitz wrote:
spip
Although I do agree with Jojo, that MAX_IO_SIZE seems to be a platform
constant and should
Hi there
While investigating the problem with hung git-upload-pack we think to have
found a bug in wrapper.c:
#define MAX_IO_SIZE (8*1024*1024)
This is then used in xread() to split read()s into suitable chunks.
So far so good, but read() is only guaranteed to read as much as SSIZE_MAX
bytes
Joachim Schmitz jojo at schmitz-digital.de writes:
because xpread() returns something 0.
something 0 of course (presumably -1)...
bye, Jojo
--
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
-Original Message-
Sent: February 7, 2015 11:26 AM
In HP-Nonstop we're experiencing hangs in git-upload-pack, which seems to
be the result
of reads from / writes to pipes don't ever finish or don't get interrupted
properly (SIGPIPE, SIGCHLD?)
Any idea why that might be and how to fix it?
On 2015-02-07 17.45, Joachim Schmitz wrote:
Hi there
While investigating the problem with hung git-upload-pack we think to have
found a bug in wrapper.c:
#define MAX_IO_SIZE (8*1024*1024)
This is then used in xread() to split read()s into suitable chunks.
So far so good, but read() is
Hi there
In HP-Nonstop we're experiencing hangs in git-upload-pack, which seems to
be the result of reads from / writes to pipes don't ever finish or don't
get interrupted properly (SIGPIPE, SIGCHLD?)
Any idea why that might be and how to fix it?
bye, Jojo
--
To unsubscribe from this list:
Torsten Bögershausen tboegi at web.de writes:
On 2015-02-07 17.45, Joachim Schmitz wrote:
snip
How about changing wrapper.c like this:
#ifndef MAX_IO_SIZE
#define MAX_IO_SIZE (8*1024*1024)
#endif
-
and to change config.mak.uname like this:
ifeq
Joachim Schmitz jojo at schmitz-digital.de writes:
snip
and as a (rather strange)
consequence mmap() (from compat/mmap.c) fails with EACCESS (why
EACCESS?),
because xpread() returns something 0.
Seems mmap() should either set errno to EINVAL or not set it at all an
just 'forward'
Christian Couder chrisc...@tuxfamily.org writes:
This way people who always want trimed trailers
don't need to specify it on the command line.
I sense that print_all() that cares about trimming illustrate a
design mistake in the original code structure. Why isn't the entire
program structured
On 2015-02-07 18.29, Joachim Schmitz wrote:
Torsten Bögershausen tboegi at web.de writes:
On 2015-02-07 17.45, Joachim Schmitz wrote:
snip
How about changing wrapper.c like this:
#ifndef MAX_IO_SIZE
#define MAX_IO_SIZE (8*1024*1024)
#endif
-
and to change
Junio C Hamano gitster at pobox.com writes:
On Sat, Feb 7, 2015 at 12:32 PM, Torsten Bögershausen tboegi at
web.de wrote:
I don't know every platform of the planet well enough to be helpful
here,
especially the ones which don't follow all the specifications.
In other words: As long
On 06.02.2015 22:28, Sergey Organov wrote:
# Now rebase my work.
git rebase -f HEAD~1
# What? Where is my Precious change in a???
cat a
/SCRIPT
I.e., the modification marked [!] was silently lost during rebase!
Just a wild guess: Maybe because you omitted -p / --preserve-merges
from git
On Feb 7 2015 at 9:14 PM Junio C Hamano wrote:
On Sat, Feb 7, 2015 at 2:31 PM, Joachim Schmitz j...@schmitz-digital.de
wrote:
Junio C Hamano gitster at pobox.com writes:
Yup, I agree that is a sensible way to go.
(1) if Makefile overrides the size, use it; otherwise
(2) if SSIZE_MAX is
On Sat, Feb 7, 2015 at 12:32 PM, Torsten Bögershausen tbo...@web.de wrote:
I don't know every platform of the planet well enough to be helpful here,
especially the ones which don't follow all the specifications.
In other words: As long as we can not guarantee that SSIZE_MAX is defined,
(and
On Sat, Feb 7, 2015 at 9:20 PM, Junio C Hamano gits...@pobox.com wrote:
Christian Couder chrisc...@tuxfamily.org writes:
This way people who always want trimed trailers
don't need to specify it on the command line.
I sense that print_all() that cares about trimming illustrate a
design
On Sat, Feb 7, 2015 at 2:31 PM, Joachim Schmitz j...@schmitz-digital.de wrote:
Junio C Hamano gitster at pobox.com writes:
Yup, I agree that is a sensible way to go.
(1) if Makefile overrides the size, use it; otherwise
(2) if SSIZE_MAX is defined, and it is smaller than our internal
22 matches
Mail list logo
