delta/git.git/write_or_die.c, branch fg/document-commit-message-stripping

refs: write packed_refs file using stdio

2014-09-10T17:58:32+00:00

We write each line of a new packed-refs file individually
using a write() syscall (and sometimes 2, if the ref is
peeled). Since each line is only about 50-100 bytes long,
this creates a lot of system call overhead.

We can instead open a stdio handle around our descriptor and
use fprintf to write to it. The extra buffering is not a
problem for us, because nobody will read our new packed-refs
file until we call commit_lock_file (by which point we have
flushed everything).

On a pathological repository with 8.5 million refs, this
dropped the time to run `git pack-refs` from 20s to 6s.

Signed-off-by: Jeff King 
Reviewed-by: Michael Haggerty 
Signed-off-by: Junio C Hamano

write_or_die: raise SIGPIPE when we get EPIPE

2013-02-20T21:42:21+00:00

The write_or_die function will always die on an error,
including EPIPE. However, it currently treats EPIPE
specially by suppressing any error message, and by exiting
with exit code 0.

Suppressing the error message makes some sense; a pipe death
may just be a sign that the other side is not interested in
what we have to say. However, exiting with a successful
error code is not a good idea, as write_or_die is frequently
used in cases where we want to be careful about having
written all of the output, and we may need to signal to our
caller that we have done so (e.g., you would not want a push
whose other end has hung up to report success).

This distinction doesn't typically matter in git, because we
do not ignore SIGPIPE in the first place. Which means that
we will not get EPIPE, but instead will just die when we get
a SIGPIPE. But it's possible for a default handler to be set
by a parent process, or for us to add a callsite inside one
of our few SIGPIPE-ignoring blocks of code.

This patch converts write_or_die to actually raise SIGPIPE
when we see EPIPE, rather than exiting with zero. This
brings the behavior in line with the "normal" case that we
die from SIGPIPE (and any callers who want to check why we
died will see the same thing). We also give the same
treatment to other related functions, including
write_or_whine_pipe and maybe_flush_or_die.

Signed-off-by: Jeff King 
Signed-off-by: Junio C Hamano

maybe_flush_or_die: move a too-loose Windows specific error

2012-10-17T07:33:42+00:00

 check to compat

Commit b2f5e268 (Windows: Work around an oddity when a pipe with no reader
is written to) introduced a check for EINVAL after fflush() to fight
spurious "Invalid argument" errors on Windows when a pipe was broken. But
this check may hide real errors on systems that do not have the this odd
behavior. Introduce an fflush wrapper in compat/mingw.* so that the treatment
is only applied on Windows.

Signed-off-by: Johannes Sixt 
Signed-off-by: Junio C Hamano

Convert existing die(..., strerror(errno)) to die_errno()

2009-06-27T18:14:53+00:00

Change calls to die(..., strerror(errno)) to use the new die_errno().

In the process, also make slight style adjustments: at least state
_something_ about the function that failed (instead of just printing
the pathname), and put paths in single quotes.

Signed-off-by: Thomas Rast 
Signed-off-by: Junio C Hamano

Move read_in_full() and write_in_full() to wrapper.c

2008-07-21T00:17:09+00:00

A few compat/* layer functions call these functions, but we would really
want to keep them thin, without depending too much on the libgit proper.

Signed-off-by: Junio C Hamano

Windows: Work around an oddity when a pipe with no reader is written to.

2008-06-26T06:47:15+00:00

On Windows, write() is implemented using WriteFile(). After the reader
closed its end of the pipe, the first WriteFile() returns
ERROR_BROKEN_PIPE (which translates to EPIPE), subsequent WriteFile()s
return ERROR_NO_DATA, which is translated to EINVAL.

Signed-off-by: Johannes Sixt

Make pack creation always fsync() the result

2008-05-31T21:46:57+00:00

This means that we can depend on packs always being stable on disk,
simplifying a lot of the object serialization worries.  And unlike loose
objects, serializing pack creation IO isn't going to be a performance
killer.

Signed-off-by: Linus Torvalds 
Signed-off-by: Junio C Hamano

Make read_in_full() and write_in_full() consistent with xread() and xwrite()

2008-04-30T06:11:57+00:00

xread() and xwrite() return ssize_t values as their native POSIX
counterparts read(2) and write(2).

To be consistent, read_in_full() and write_in_full() should also return
ssize_t values.

Signed-off-by: Junio C Hamano

Don't fflush(stdout) when it's not helpful

2007-07-01T03:16:12+00:00

This patch arose from a discussion started by Jim Meyering's patch
whose intention was to provide better diagnostics for failed writes.
Linus proposed a better way to do things, which also had the added
benefit that adding a fflush() to git-log-* operations and incremental
git-blame operations could improve interactive respose time feel, at
the cost of making things a bit slower when we aren't piping the
output to a downstream program.

This patch skips the fflush() calls when stdout is a regular file, or
if the environment variable GIT_FLUSH is set to "0".  This latter can
speed up a command such as:

GIT_FLUSH=0 strace -c -f -e write time git-rev-list HEAD | wc -l

a tiny amount.

Signed-off-by: "Theodore Ts'o" 
Acked-by: Linus Torvalds 
Signed-off-by: Junio C Hamano

write_in_full: size_t is unsigned.

2007-01-27T01:39:03+00:00

It received the return value from xwrite() in a size_t variable
'written' and expected comparison with 0 would catch an error
from xwrite().

Signed-off-by: Junio C Hamano