Re: [PATCH v4 11/25] checkout: fix memory leak

Am 04.05.2017 um 15:56 schrieb Johannes Schindelin: This change addresses part of the NEEDSWORK comment above the code, therefore the comment needs to be adjusted, too. Discovered via Coverity. Signed-off-by: Johannes Schindelin --- builtin/checkout.c | 17

[PATCH] am: check return value of resolve_refdup before using hash

If resolve_refdup() fails it returns NULL and possibly leaves its hash output parameter untouched. Make sure to use it only if the function succeeded, in order to avoid accessing uninitialized memory. Signed-off-by: Rene Scharfe --- builtin/am.c | 2 +- 1 file changed, 1

[PATCH] checkout: check return value of resolve_refdup before using hash

If resolve_refdup() fails it returns NULL and possibly leaves its hash output parameter untouched. Make sure to use it only if the function succeeded, in order to avoid accessing uninitialized memory. Found with t/t2011-checkout-invalid-head.sh --valgrind. Signed-off-by: Rene Scharfe

Re: [PATCH v3 12/25] split_commit_in_progress(): fix memory leak

Am 02.05.2017 um 18:02 schrieb Johannes Schindelin: Reported via Coverity. Signed-off-by: Johannes Schindelin --- wt-status.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/wt-status.c b/wt-status.c index 0a6e16dbe0f..1f3f6bcb980 100644

Re: [PATCH v3 01/25] mingw: avoid memory leak when splitting PATH

Am 02.05.2017 um 18:00 schrieb Johannes Schindelin: In the (admittedly, concocted) case that PATH consists only of colons, we would leak the duplicated string. Nit: It's about semicolons, right? At least that's what get_path_split is searching for. Or is there some kind of translation going

Re: [PATCH v3 02/25] winansi: avoid use of uninitialized value

Am 02.05.2017 um 18:01 schrieb Johannes Schindelin: When stdout is not connected to a Win32 console, we incorrectly used an uninitialized value for the "plain" character attributes. Detected by Coverity. Signed-off-by: Johannes Schindelin --- compat/winansi.c | 2

Re: [PATCH 1/5] add SWAP macro

Am 30.04.2017 um 05:11 schrieb Jeff King: > On Sat, Apr 29, 2017 at 08:16:17PM +0200, René Scharfe wrote: > >>> I dunno. I could go either way. Or we could leave it as-is, and let >>> valgrind find the problem. That has zero run-time cost, but of course >>> nobod

Re: [PATCH] cache-tree: reject entries with null sha1

Am 01.05.2017 um 21:22 schrieb Jeff King: On Mon, May 01, 2017 at 01:23:28PM +0200, René Scharfe wrote: I can only get gcc and clang to call memcpy instead of inlining it by specifying -fno-builtin. Do you use that option? If yes, why? (Just curious.) I do my normal edit-compile cycles

Re: [PATCH] cache-tree: reject entries with null sha1

Am 01.05.2017 um 13:23 schrieb René Scharfe: But I can't get Valgrind to report overlapping (nicely explained in http://valgrind.org/docs/manual/mc-manual.html#mc-manual.overlap, by the way), not for t7009 and not for the short test program at the bottom. Do you set flags

Re: [PATCH] cache-tree: reject entries with null sha1

Am 24.04.2017 um 12:39 schrieb Duy Nguyen: BTW, I ran t7009 with valgrind and it reported this. Is it something we should be worried about? I vaguely recall you're doing something with prio-queue... ==4246== Source and destination overlap in memcpy(0x5952990, 0x5952990, 16) ==4246==at

Re: [PATCH v3 0/5] archive-zip: support files and archives bigger than 4GB

Am 01.05.2017 um 01:49 schrieb Junio C Hamano: René Scharfe <l@web.de> writes: Am 30.04.2017 um 18:32 schrieb Johannes Sixt: Am 30.04.2017 um 09:53 schrieb René Scharfe: @@ -178,7 +182,8 @@ test_expect_success EXPENSIVE,UNZIP 'zip archive bigger than 4GB' ' "$GIT_UNZ

Re: [PATCH v3 0/5] archive-zip: support files and archives bigger than 4GB

Am 30.04.2017 um 18:32 schrieb Johannes Sixt: Am 30.04.2017 um 09:53 schrieb René Scharfe: @@ -178,7 +182,8 @@ test_expect_success EXPENSIVE,UNZIP 'zip archive bigger than 4GB' ' "$GIT_UNZIP" -t many-big.zip ' -test_expect_success EXPENSIVE,UNZIP,ZIPINFO 'zip archive with fil

Re: [PATCH v3 0/5] archive-zip: support files and archives bigger than 4GB

Am 30.04.2017 um 07:31 schrieb Torsten Bögershausen: > Sorry, I was not looking careful enough, the macro `$GIT_UNZIP` > gave the impression that an unzip provided by Git (or the Git test > framework) was used :-( > > $ which unzip > /usr/bin/unzip > > $ unzip -v > UnZip 5.52 of 28 February

Re: [PATCH v3 0/5] archive-zip: support files and archives bigger than 4GB

Am 29.04.2017 um 23:00 schrieb Torsten Bögershausen: > This fails here under Mac OS: > commit 4cdf3f9d84568da72f1dcade812de7a42ecb6d15 > Author: René Scharfe <l@web.de> > Date: Mon Apr 24 19:33:34 2017 +0200 > > archive-zip: suppo

Re: [PATCH 1/5] add SWAP macro

Am 28.04.2017 um 23:49 schrieb Jeff King: On Fri, Apr 28, 2017 at 07:04:51PM +0200, René Scharfe wrote: What should: SWAP(foo[i], foo[j]); do when i == j? With this code, it ends up calling memcpy([i], [j], ...); which can cause valgrind to complain about overlapping memory. I

Re: [PATCH 1/5] add SWAP macro

Am 24.04.2017 um 13:29 schrieb Jeff King: On Sat, Jan 28, 2017 at 10:38:21PM +0100, René Scharfe wrote: diff --git a/git-compat-util.h b/git-compat-util.h index 87237b092b..66cd466eea 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -527,6 +527,16 @@ static inline int ends_with(const

Re: What's cooking in git.git (Apr 2017, #06; Wed, 26)

Am 27.04.2017 um 04:54 schrieb Junio C Hamano: > * rs/large-zip (2017-04-24) 5 commits >(merged to 'next' on 2017-04-26 at a6beab60f2) > + archive-zip: support files bigger than 4GB > + archive-zip: support archives bigger than 4GB > + archive-zip: write ZIP dir entry directly to strbuf

Re: [PATCH v3 4/5] archive-zip: support archives bigger than 4GB

Am 27.04.2017 um 06:57 schrieb Peter Krefting: > René Scharfe: >> Windows XP. Don't laugh. ;) > > You can always install 7-zip or something to extract on XP. Sure, but if we were to start emitting zip64 records regardless of the size of entries then we'd break compatibility.

Re: [PATCH v3 4/5] archive-zip: support archives bigger than 4GB

Am 26.04.2017 um 23:02 schrieb Peter Krefting: René Scharfe: I struggled with that sentence as well. There is no explicit "format" field AFAICS. Exactly. I interpret that as it is in zip64 format if there are any zip64 structures in the archive (especially if there is a

Re: [PATCH v5 6/8] Introduce a new data type for timestamps

Am 24.04.2017 um 15:58 schrieb Johannes Schindelin: diff --git a/archive-tar.c b/archive-tar.c index 380e3aedd23..695339a2369 100644 --- a/archive-tar.c +++ b/archive-tar.c @@ -27,9 +27,12 @@ static int write_tar_filter_archive(const struct archiver *ar, */ #if ULONG_MAX == 0x

Re: [PATCH v5 0/8] Introduce timestamp_t for timestamps

Hi Dscho, Am 26.04.2017 um 00:22 schrieb Johannes Schindelin: On Tue, 25 Apr 2017, René Scharfe wrote: Am 24.04.2017 um 15:57 schrieb Johannes Schindelin: Can we leave time_t alone and just do the part where you replace unsigned long with timestamp_t defined as uint64_t? That should already

Re: [PATCH v5 0/8] Introduce timestamp_t for timestamps

Am 24.04.2017 um 15:57 schrieb Johannes Schindelin: Git v2.9.2 was released in a hurry to accomodate for platforms like Windows, where the `unsigned long` data type is 32-bit even for 64-bit setups. The quick fix was to simply disable all the testing with "absurd" future dates. However, we can

Re: [PATCH v3 4/5] archive-zip: support archives bigger than 4GB

Am 25.04.2017 um 09:55 schrieb Peter Krefting: René Scharfe: This needs to be >=. The spec says that if the value is 0x, there should be a zip64 record with the actual size (even if it is 0x). Could you please cite the relevant part? 4.4.8 compressed size: (4 bytes) 4.

Re: [PATCH v3 5/5] archive-zip: support files bigger than 4GB

Am 25.04.2017 um 06:46 schrieb Junio C Hamano: René Scharfe <l@web.de> writes: diff --git a/t/t5004-archive-corner-cases.sh b/t/t5004-archive-corner-cases.sh index 0ac94b5cc9..a6875dfdb1 100755 --- a/t/t5004-archive-corner-cases.sh +++ b/t/t5004-archive-corner-cases.sh @@ -178,7

Re: [PATCH v3 2/5] archive-zip: use strbuf for ZIP directory

Am 25.04.2017 um 06:51 schrieb Junio C Hamano: René Scharfe <l@web.de> writes: Keep the ZIP central director, which is written after all archive Is this typoed "directorY"? I know there was discussion on the correct terminology I only skimmed and I am too

Re: [PATCH v3 4/5] archive-zip: support archives bigger than 4GB

Am 24.04.2017 um 23:02 schrieb Johannes Sixt: Am 24.04.2017 um 22:06 schrieb René Scharfe: Am 24.04.2017 um 20:24 schrieb Peter Krefting: René Scharfe: @@ -433,6 +446,11 @@ static int write_zip_entry(struct archiver_args *args, free(deflated); free(buffer); +if (offset

Re: [PATCH v3 4/5] archive-zip: support archives bigger than 4GB

Am 24.04.2017 um 22:06 schrieb René Scharfe: Am 24.04.2017 um 20:24 schrieb Peter Krefting: René Scharfe: Also set the version required to 45 (4.5) for any record that has zip64 fields. Ah, yes indeed. When I tried to implement this I realized that should set 20 for directories, but we

Re: [PATCH v3 4/5] archive-zip: support archives bigger than 4GB

Am 24.04.2017 um 20:24 schrieb Peter Krefting: René Scharfe: @@ -433,6 +446,11 @@ static int write_zip_entry(struct archiver_args *args, free(deflated); free(buffer); +if (offset > 0x) { +zip64_dir_extra_payload_size += 8; +zip_dir_extra_size += 2

[PATCH v3 5/5] archive-zip: support files bigger than 4GB

Write a zip64 extended information extra field for big files as part of their local headers and as part of their central directory headers. Also write a zip64 version of the data descriptor in that case. If we're streaming then we don't know the compressed size at the time we write the header.

[PATCH v3 4/5] archive-zip: support archives bigger than 4GB

Add a zip64 extended information extra field to the central directory and emit the zip64 end of central directory records as well as locator if the offset of an entry within the archive exceeds 4GB. Signed-off-by: Rene Scharfe --- archive-zip.c | 32

[PATCH v3 3/5] archive-zip: write ZIP dir entry directly to strbuf

Write all fields of the ZIP directory record for an archive entry in the right order directly into the strbuf instead of taking a detour through a struct. Do that at end, when we have all necessary data like checksum and compressed size. The fields are documented just as well, the code becomes

[PATCH v3 2/5] archive-zip: use strbuf for ZIP directory

Keep the ZIP central director, which is written after all archive entries, in a strbuf instead of a custom-managed buffer. It contains binary data, so we can't (and don't want to) use the full range of strbuf functions and we don't need the terminating NUL, but the result is shorter and simpler

[PATCH v3 1/5] archive-zip: add tests for big ZIP archives

Test the creation of ZIP archives bigger than 4GB and containing files bigger than 4GB. They are marked as EXPENSIVE because they take quite a while and because the first one needs a bit more than 4GB of disk space to store the resulting archive. The big archive in the first test is made up of a

[PATCH v3 0/5] archive-zip: support files and archives bigger than 4GB

The first patch adds (expensive) tests, the next two are cleanups which set the stage for the remaining two to actually implement zip64 support for offsets and file sizes. Half of the series had been laying around for months, half-finished and forgotten because I got distracted by the holiday

Re: [PATCH v2] archive-zip: Add zip64 headers when file size is too large for 32 bits

Am 24.04.2017 um 10:04 schrieb Peter Krefting: Johannes Sixt: There is no "zip64 central directory". There is a "zip64 end of central directory record"; Not strange that I was confused and couldn't find it, then... :-) All right, I need to fix up my patch to make sure I add the zip64 extra

Re: [PATCH] archive-zip: Add zip64 headers when file size is too large for 32 bits

Am 22.04.2017 um 23:52 schrieb Johannes Sixt: Am 22.04.2017 um 21:22 schrieb Peter Krefting: @@ -279,6 +299,7 @@ static int write_zip_entry(struct archiver_args *args, int is_binary = -1; const char *path_without_prefix = path + args->baselen; unsigned int creator_version = 0; +

Re: [PATCH v3 1/2] use HOST_NAME_MAX to size buffers for gethostname(2)

Am 20.04.2017 um 20:37 schrieb Torsten Bögershausen: On 2017-04-19 22:02, René Scharfe wrote: Am 19.04.2017 um 21:09 schrieb Torsten Bögershausen: On 2017-04-19 19:28, René Scharfe wrote: [] One or two minor comments inline diff --git a/builtin/gc.c b/builtin/gc.c index 2daede7820..4c1c01e87d

Re: [PATCH v3 1/2] use HOST_NAME_MAX to size buffers for gethostname(2)

Am 19.04.2017 um 21:09 schrieb Torsten Bögershausen: On 2017-04-19 19:28, René Scharfe wrote: [] One or two minor comments inline diff --git a/builtin/gc.c b/builtin/gc.c index 2daede7820..4c1c01e87d 100644 --- a/builtin/gc.c +++ b/builtin/gc.c @@ -228,21 +228,99 @@ static int need_to_gc(void

Re: [PATCH v3 1/2] use HOST_NAME_MAX to size buffers for gethostname(2)

Am 19.04.2017 um 03:28 schrieb Jonathan Nieder: > David Turner wrote: >> @@ -274,7 +278,7 @@ static const char *lock_repo_for_gc(int force, pid_t* >> ret_pid) >> * running. >> */ >> time(NULL) - st.st_mtime <= 12 * 3600 && >> -

Re: [PATCH v3 2/2] xgethostname: handle long hostnames

Am 19.04.2017 um 17:50 schrieb David Turner: >> -Original Message- >> From: Junio C Hamano [mailto:gits...@pobox.com] >> Sent: Tuesday, April 18, 2017 10:51 PM >> To: Jonathan Nieder >> Cc: David Turner ; git@vger.kernel.org; >> l@web.de

Re: [PATCH v3 1/2] use HOST_NAME_MAX to size buffers for gethostname(2)

Am 19.04.2017 um 03:28 schrieb Jonathan Nieder: >> From: René Scharfe <l@web.de> >> >> POSIX limits the length of host names to HOST_NAME_MAX. Export the >> fallback definition from daemon.c and use this constant to make all >> buffers used with gethos

Re: [PATCH] various: disallow --no-no-OPT for --no-opt options

Am 19.04.2017 um 15:19 schrieb Ævar Arnfjörð Bjarmason: I mean a bug in my patch, i.e. I meant to remove --no-no-OPT in cases of --no-OPT but also removed --OPT unintentionally, but anyway, let's drop this one, Jacob's patch is better. Ah, OK. You also wondered why no tests complained. Good

Re: [PATCH] various: disallow --no-no-OPT for --no-opt options

Am 19.04.2017 um 09:00 schrieb Ævar Arnfjörð Bjarmason: On Wed, Apr 19, 2017 at 12:29 AM, René Scharfe <l@web.de> wrote: Setting PARSE_OPT_NONEG takes away the ability to toggle the affected option. E.g. git clone would reject --checkout. Currently users can specify --no- o

Re: [RFC PATCH] parse-options: disallow double-negations of options starting with no-

Am 19.04.2017 um 11:08 schrieb Jacob Keller: From: Jacob Keller Many options can be negated by prefixing the option with "no-", for example "--3way" can be prefixed with "--no-3way" to disable it. Since 0f1930c58754 ("parse-options: allow positivation of options

Re: [PATCH] various: disallow --no-no-OPT for --no-opt options

Am 18.04.2017 um 19:09 schrieb Ævar Arnfjörð Bjarmason: Change various --no-OPT options which don't supply PARSE_OPT_NONEG to make --no-no-OPT an error. All of these worked before this change, e.g. doing cloning by doing "git clone --no-no-checkout" is equivalent to just "git clone", but this

Re: [PATCH v2] xgethostname: handle long hostnames

Am 18.04.2017 um 03:41 schrieb Junio C Hamano: > Junio C Hamano writes: > >> David Turner writes: >> >>> @@ -250,14 +250,14 @@ static const char *lock_repo_for_gc(int force, pid_t* >>> ret_pid) >>> ... >>> if (!force) { >>> - static char

Re: What's cooking in git.git (Apr 2017, #02; Sun, 16)

Am 17.04.2017 um 09:30 schrieb Junio C Hamano: > * dt/xgethostname-nul-termination (2017-04-13) 1 commit > - xgethostname: handle long hostnames > > gethostname(2) may not NUL terminate the buffer if hostname does > not fit; unfortunately there is no easy way to see if our buffer > was

[PATCH] files_for_each_reflog_ent_reverse(): close stream and free strbuf on error

Exit the loop orderly through the cleanup code, instead of dashing out with logfp still open and sb leaking. Found with Cppcheck. Signed-off-by: Rene Scharfe --- refs/files-backend.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git

[PATCH] server-info: avoid calling fclose(3) twice in update_info_file()

If an error occurs when or after closing the stream we call fclose(3) again in the error handler. The second call can exhibit undefined behavior, so make sure to call fclose(3) at most once. Also avoid calling close(2) after fd has been successfully associated with the stream, as fclose(3) has

[PATCH] am: close stream on error, but not stdin

Avoid closing stdin, but do close an actual input file on error exit. Found with Cppcheck. Signed-off-by: Rene Scharfe --- builtin/am.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/builtin/am.c b/builtin/am.c index f7a7a971fb..805f56cec2 100644 ---

Re: [PATCH v10 3/3] read-cache: speed up add_index_entry during checkout

Am 14.04.2017 um 21:12 schrieb g...@jeffhostetler.com: From: Jeff Hostetler Teach add_index_entry_with_check() and has_dir_name() to see if the path of the new item is greater than the last path in the index array before attempting to search for it. During checkout,

Re: [PATCH] xgethostname: handle long hostnames

Am 13.04.2017 um 21:23 schrieb David Turner: > If the full hostname doesn't fit in the buffer supplied to > gethostname, POSIX does not specify whether the buffer will be > null-terminated, so to be safe, we should do it ourselves. Introduce > new function, xgethostname, which ensures that there

Re: [PATCH v2] unpack-trees: avoid duplicate ODB lookups during checkout

Am 10.04.2017 um 23:26 schrieb Jeff Hostetler: > On 4/8/2017 10:06 AM, René Scharfe wrote: >> Am 07.04.2017 um 17:53 schrieb g...@jeffhostetler.com: >>> +/* implicitly borrow buf[i-1] inside tree_desc[i] */ >>> +memcpy([i], [i-

Re: [PATCH v2] unpack-trees: avoid duplicate ODB lookups during checkout

Am 07.04.2017 um 17:53 schrieb g...@jeffhostetler.com: From: Jeff Hostetler Teach traverse_trees_recursive() to not do redundant ODB lookups when both directories refer to the same OID. In operations such as read-tree, checkout, and merge when the differences between

[PATCH 2/2] use MOVE_ARRAY

Add a semantic patch for converting certain calls of memmove(3) to MOVE_ARRAY() and apply that transformation to the code base. The result is shorter and safer code. Signed-off-by: Rene Scharfe --- apply.c| 7 +++ builtin/ls-files.c | 3

Re: [PATCH v3 1/2] Fix nonnull errors reported by UBSAN with GCC 7.

Am 07.04.2017 um 16:23 schrieb Martin Liška: On 04/06/2017 10:49 PM, Johannes Sixt wrote: Am 06.04.2017 um 19:31 schrieb René Scharfe: Am 06.04.2017 um 18:33 schrieb Johannes Sixt: Am 06.04.2017 um 17:42 schrieb Martin Liška: +static inline void *sane_memmove(void *dest, const void *src

[PATCH 1/2] add MOVE_ARRAY

Add MOVE_ARRAY to complement COPY_ARRAY, which was added in 60566cbb. It provides the same convenience, safety and support for NULL pointers as representations of empty arrays, just as a wrapper for memmove(3) instead of memcpy(3). Inspired-by: Martin Liska Signed-off-by: Rene

Re: [PATCH v1] unpack-trees: avoid duplicate ODB lookups during checkout

Am 06.04.2017 um 22:37 schrieb g...@jeffhostetler.com: From: Jeff Hostetler Teach traverse_trees_recursive() to not do redundant ODB lookups when both directories refer to the same OID. In operations such as read-tree, checkout, and merge when the differences between

Re: [PATCH v6 1/3] read-cache: add strcmp_offset function

Am 06.04.2017 um 18:34 schrieb g...@jeffhostetler.com: diff --git a/read-cache.c b/read-cache.c index 9054369..e8f1900 100644 --- a/read-cache.c +++ b/read-cache.c @@ -887,6 +887,26 @@ static int has_file_name(struct index_state *istate, return retval; } + +/* + * Like strcmp(),

[PATCH] test-read-cache: setup git dir

b1ef400e (setup_git_env: avoid blind fall-back to ".git") made programs that tried to access a repository without initializing properly die with a diagnostic message. One offender is test-read-cache, which is used in p0002. Fix it by calling setup_git_directory() before accessing the index.

Re: [PATCH v5 3/4] test-strcmp-offset: created test for strcmp_offset

Am 05.04.2017 um 19:38 schrieb g...@jeffhostetler.com: diff --git a/t/helper/test-strcmp-offset.c b/t/helper/test-strcmp-offset.c new file mode 100644 index 000..fe01318 --- /dev/null +++ b/t/helper/test-strcmp-offset.c @@ -0,0 +1,64 @@ +#include "cache.h" + +struct test_data { + const

Re: [PATCH v5 1/4] p0004-read-tree: perf test to time read-tree

Am 05.04.2017 um 19:38 schrieb g...@jeffhostetler.com: > From: Jeff Hostetler > > Signed-off-by: Jeff Hostetler > --- > t/perf/p0004-read-tree.sh | 116 > ++ > 1 file changed, 116 insertions(+) >

Re: [PATCH v3 1/2] Fix nonnull errors reported by UBSAN with GCC 7.

Am 06.04.2017 um 18:33 schrieb Johannes Sixt: Am 06.04.2017 um 17:42 schrieb Martin Liška: +static inline void *sane_memmove(void *dest, const void *src, size_t n) +{ +if (n > 0) +return memmove(dest, src, n); +else +return dest; +} Huh? memmove with n == 0 is

Re: [PATCH v2 1/2] Fix nonnull errors reported by UBSAN with GCC 7.

Am 06.04.2017 um 11:52 schrieb Martin Liška: > I'm sending (v2), where I updated commit message and wrapped 2 problematic > places to newly introduced macros that do the check. Follow-up patch can > change usages of memcpy and memove. > diff --git a/apply.c b/apply.c > index e6dbab26a..eacca29fa

Re: [PATCH] strbuf: support long paths w/o read rights in strbuf_getcwd() on FreeBSD

Am 29.03.2017 um 06:54 schrieb Christian Couder: On Tue, Mar 28, 2017 at 11:49 PM, Jeff King <p...@peff.net> wrote: On Tue, Mar 28, 2017 at 11:15:12PM +0200, Christian Couder wrote: On Sun, Mar 26, 2017 at 3:43 PM, René Scharfe <l@web.de> wrote: FreeBSD implements getcwd(3)

[PATCH] strbuf: support long paths w/o read rights in strbuf_getcwd() on FreeBSD

FreeBSD implements getcwd(3) as a syscall, but falls back to a version based on readdir(3) if it fails for some reason. The latter requires permissions to read and execute path components, while the former does not. That means that if our buffer is too small and we're missing rights we could get

Re: [PATCH] pretty: add extra headers and MIME boundary directly

Am 25.03.2017 um 22:11 schrieb Jeff King: > The most correct way is that the caller of log_write_email_headers() and > diff_flush() should have a function-local strbuf which holds the data, > gets passed to diff_flush() as some kind opaque context, and then is > freed afterwards. We don't have

Re: [PATCH] pretty: add extra headers and MIME boundary directly

Am 25.03.2017 um 17:17 schrieb Jeff King: On Sat, Mar 25, 2017 at 01:16:42PM +0100, René Scharfe wrote: @@ -374,26 +372,9 @@ void log_write_email_headers(struct rev_info *opt, struct commit *commit, graph_show_oneline(opt->graph); } if (opt->mime_bo

[PATCH] pretty: add extra headers and MIME boundary directly

Use the after_subject member of struct pretty_print_context to pass the extra_headers unchanged, and construct and add the MIME boundary headers directly in pretty.c::pp_title_line() instead of writing both to a static buffer in log-tree.c::log_write_email_headers() first. That's easier, quicker

Re: [PATCH] refs.c: use skip_prefix() in prettify_refname()

Am 23.03.2017 um 20:39 schrieb Jeff King: On Thu, Mar 23, 2017 at 12:33:06PM -0700, Junio C Hamano wrote: Nice, but why add the "if" when it's doing nothing? It's short-circuiting in the conditional. I think René meant this: /* just for side effects */ skip_prefix(name,

Re: [PATCH] refs.c: use skip_prefix() in prettify_refname()

Am 23.03.2017 um 20:33 schrieb Junio C Hamano: Jeff King <p...@peff.net> writes: On Thu, Mar 23, 2017 at 08:18:26PM +0100, René Scharfe wrote: Am 23.03.2017 um 16:50 schrieb SZEDER Gábor: This eliminates three magic numbers. Signed-off-by: SZEDER Gábor <szeder@gmail.com>

Re: Question: libxdiff: text-patches: internal format

Am 23.03.2017 um 19:00 schrieb matt...@giassa.net: Hi there, Following up on an earlier question of mine from yesterday, is there any formal documentation (save for source diving) on the internal format used by libxdiff/xdiff when it generates a patch by comparing two plaintext files? I'd like

Re: [PATCH] refs.c: use skip_prefix() in prettify_refname()

Am 23.03.2017 um 16:50 schrieb SZEDER Gábor: This eliminates three magic numbers. Signed-off-by: SZEDER Gábor --- refs.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/refs.c b/refs.c index e7606716d..0272e332c 100644 --- a/refs.c +++

Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

Am 21.03.2017 um 14:29 schrieb Zenobiusz Kunegunda: I think I found a way to reproduce this error. I installed FreeBSD 10.3 under qemu with zfs partitioning. Test program did not report any access errors. Then I did chmod 711 /usr/home Now program started reporting permission denied errors just

[PATCH] http-push: don't check return value of lookup_unknown_object()

This function always returns a reference to an object, creating one if needed, so remove the unnecessary NULL check. Signed-off-by: Rene Scharfe --- http-push.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/http-push.c b/http-push.c index

[PATCH] shortlog: don't set after_subject to an empty string

The string after_subject is added to a strbuf by pp_title_line() if it's not NULL. Adding an empty string has the same effect as not adding anything, but the latter is easier, so don't bother changing the context member from NULL to "". Signed-off-by: Rene Scharfe ---

Re: [PATCH] receive-pack: simplify run_update_post_hook()

Am 17.03.2017 um 23:23 schrieb Jeff King: On Fri, Mar 17, 2017 at 11:02:13PM +0100, René Scharfe wrote: Instead of counting the arguments to see if there are any and then building the full command use a single loop and add the hook command just before the first argument. This reduces

Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

Am 17.03.2017 um 23:29 schrieb Jeff King: On Fri, Mar 17, 2017 at 10:07:18PM +0100, René Scharfe wrote: As an extension to the POSIX.1-2001 standard, Linux (libc4, libc5, glibc) getcwd() allocates the buffer dynamically using malloc(3) if buf is NULL. In this case, the allocated buffer

[PATCH] revision: remove declaration of path_name()

The definition of path_name() was removed by 2824e1841 (list-objects: pass full pathname to callbacks); remove its declaration as well. Signed-off-by: Rene Scharfe --- revision.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/revision.h b/revision.h index

[PATCH] receive-pack: simplify run_update_post_hook()

Instead of counting the arguments to see if there are any and then building the full command use a single loop and add the hook command just before the first argument. This reduces duplication and overall code size. Signed-off-by: Rene Scharfe --- builtin/receive-pack.c | 13

Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

Am 17.03.2017 um 20:45 schrieb Stefan Beller: On Fri, Mar 17, 2017 at 12:34 PM, René Scharfe <l@web.de> wrote: Am 15.03.2017 um 22:30 schrieb René Scharfe: Am 15.03.2017 um 10:44 schrieb Zenobiusz Kunegunda: $ git bisect bad 7333ed1788b4f2b162a35003044d77a716732a1f is the first bad

Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

Am 15.03.2017 um 22:30 schrieb René Scharfe: > Am 15.03.2017 um 10:44 schrieb Zenobiusz Kunegunda: >> $ git bisect bad >> 7333ed1788b4f2b162a35003044d77a716732a1f is the first bad commit >> commit 7333ed1788b4f2b162a35003044d77a716732a1f >> Author: René Scharfe <l

Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

Am 15.03.2017 um 10:44 schrieb Zenobiusz Kunegunda: $ git bisect bad 7333ed1788b4f2b162a35003044d77a716732a1f is the first bad commit commit 7333ed1788b4f2b162a35003044d77a716732a1f Author: René Scharfe <l@web.de> Date: Mon Jul 28 20:26:40 2014 +0200 setup: c

Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

Am 14.03.2017 um 08:44 schrieb Zenobiusz Kunegunda: Od: "René Scharfe" l@web.de> Do: "Zenobiusz Kunegunda" zenobiusz.kunegu...@interia.pl>; Wysłane: 22:31 Poniedziałek 2017-03-13 Temat: Re: fatal: Could not get current working directory: Permission denied

Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

Am 13.03.2017 um 14:23 schrieb Zenobiusz Kunegunda: Bisecting: 0 revisions left to test after this (roughly 0 steps) [a26bc613a64ac2c7ee69a50675e61b004a26382d] pretty.c: make git_pretty_formats_config return -1 on git_config_string failure This is what I found with git bisect Strange, I

Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

Am 13.03.2017 um 13:23 schrieb Zenobiusz Kunegunda: > Tested on ZFS filesystem > > > > [test0@s0]:<~>$ mkdir > '23222' > [test0@s0]:<~>$ cd >

Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

Am 09.03.2017 um 12:01 schrieb Zenobiusz Kunegunda: OK, I printed euids inside function calling getcwd(). Every single EUID is the same and have expected value. The same as any other local application run by this user. Permissions of every directory in the path are OK. /bin/pwd -P inside

Re: [PATCH v1] Travis: also test on 32-bit Linux

Am 11.03.2017 um 00:33 schrieb Junio C Hamano: > René Scharfe <l@web.de> writes: > >> @ depends on r @ >> expression E; >> @@ >> - *& >>E > > I guess my source of the confusion is that the tool that under

Re: [PATCH v1] Travis: also test on 32-bit Linux

Am 10.03.2017 um 21:13 schrieb Junio C Hamano: René Scharfe <l@web.de> writes: I think this misses the other two cases: (*dst, src) and (*dst, *src). ... and that's why I left them out. You can't get dst vs. *dst wrong with structs (at least not without the compiler complaining)

Re: [PATCH v1] Travis: also test on 32-bit Linux

Am 10.03.2017 um 18:57 schrieb Jeff King: On Fri, Mar 10, 2017 at 05:20:13PM +0100, René Scharfe wrote: I think this misses the other two cases: (*dst, src) and (*dst, *src). ... and that's why I left them out. You can't get dst vs. *dst wrong with structs (at least not without the compiler

Re: [PATCH] Makefile: detect errors in running spatch

Am 10.03.2017 um 09:31 schrieb Jeff King: The "make coccicheck" target runs spatch against each source file. But it does so in a for loop, so "make" never sees the exit code of spatch. Worse, it redirects stderr to a log file, so the user has no indication of any failure. And then to top it all

Re: [PATCH v1] Travis: also test on 32-bit Linux

Am 10.03.2017 um 09:18 schrieb Jeff King: On Fri, Mar 10, 2017 at 01:14:16AM +0100, René Scharfe wrote: 2. Ones which just copy a single object, like: memcpy(, , sizeof(dst)); Perhaps we should be using struct assignment like: dst = src; here. It's safer

Re: [PATCH] blame: move blame_entry duplication to add_blame_entry()

Am 10.03.2017 um 09:32 schrieb Jeff King: On Fri, Mar 10, 2017 at 01:12:59AM +0100, René Scharfe wrote: All callers of add_blame_entry() allocate and copy the second argument. Let the function do it for them, reducing code duplication. I assume you found this due to the DUPLICATE

Re: [PATCH v1] Travis: also test on 32-bit Linux

Am 05.03.2017 um 12:36 schrieb Jeff King: > I grepped for 'memcpy.*sizeof' and found one other case that's not a > bug, but is questionable. > > Of the "good" cases, I think most of them could be converted into > something more obviously-correct, which would make auditing easier. The > three main

Re: [PATCH v1] Travis: also test on 32-bit Linux

Am 05.03.2017 um 12:36 schrieb Jeff King: I grepped for 'memcpy.*sizeof' and found one other case that's not a bug, but is questionable. Of the "good" cases, I think most of them could be converted into something more obviously-correct, which would make auditing easier. The three main cases I

[PATCH] blame: move blame_entry duplication to add_blame_entry()

All callers of add_blame_entry() allocate and copy the second argument. Let the function do it for them, reducing code duplication. Signed-off-by: Rene Scharfe --- builtin/blame.c | 25 - 1 file changed, 8 insertions(+), 17 deletions(-) diff --git

Re: [PATCH 2/2] Fix callsites of real_pathdup() that wanted it to die on error

Am 09.03.2017 um 12:24 schrieb Johannes Schindelin: While I would have agreed earlier that René's patch looks less intrusive, I have to point out that there would not have been any possible regression if the original patch had introduced the die_on_error parameter. It would have made the

Re: [PATCH 2/2] Fix callsites of real_pathdup() that wanted it to die on error

Am 08.03.2017 um 16:43 schrieb Johannes Schindelin: > In 4ac9006f832 (real_path: have callers use real_pathdup and > strbuf_realpath, 2016-12-12), we changed the xstrdup(real_path()) > pattern to use real_pathdup() directly. > > The only problem with this change is that real_path() calls >

Re: fatal: Could not get current working directory: Permission denied | affected 2.10,2.11,2.12, but not 1.9.5 |

Am 06.03.2017 um 17:10 schrieb Zenobiusz Kunegunda: OS: FreeBSD 10.3-STABLE Story: I was trying to install openproject using this manual https://www.openproject.org/open-source/download/manual-installation-guide/ Everything was fine till command $ bundle install --deployment --without

Re: git status --> Out of memory, realloc failed

Am 01.03.2017 um 21:12 schrieb Carsten Fuchs: Hi René, Am 01.03.2017 um 11:02 schrieb René Scharfe: I use Git at a web hosting service, where my user account has a memory limit of 768 MB: (uiserver):p7715773:~$ uname -a Linux infongp-de15 3.14.0-ui16322-uiabi1-infong-amd64 #1 SMP Debian

<    1   2   3   4   5   6   7   8   9   10   >