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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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.
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
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
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
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
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
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.
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
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
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
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
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
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
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;
+
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
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
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 &&
>> -
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
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
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
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
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
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
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
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
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
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
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
---
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,
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
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-
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
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
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
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
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
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(),
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.
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
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(+)
>
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
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
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)
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
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
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
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
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,
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>
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
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
+++
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
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
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
---
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
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
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
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
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
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
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
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
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
Am 13.03.2017 um 13:23 schrieb Zenobiusz Kunegunda:
> Tested on ZFS filesystem
>
>
>
> [test0@s0]:<~>$ mkdir
> '23222'
> [test0@s0]:<~>$ cd
>
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
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
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)
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
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
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
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
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
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
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
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
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
>
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
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
401 - 500 of 1163 matches
Mail list logo