Am 11.08.2018 um 18:48 schrieb Jeff King:
And one I'm not sure about:
- a read() error will now be quietly ignored; I guess we'd have to
check ferror(fp) to cover this. I'm not sure if it matters.
I'm not sure, either. It would catch media errors or file system
corruption, right? Sound
Object IDs to skip are stored in a shared static oid_array. Lookups do
a binary search on the sorted array. The code checks if the object IDs
are already in the correct order while loading and skips sorting in that
case.
Simplify the code by using an oidset instead. Memory usage is a bit
highe
The char array named "buffer" is unlikely to contain a NUL character, so
printing its contents using %s in a die() format is unsafe. Clang's
ASan reports running over the end of buffer in the recently added
skiplist tests in t5504-fetch-receive-strict.sh as a result.
Use an idiomatic strbuf_getl
Am 02.08.2018 um 22:36 schrieb Junio C Hamano:
> Ævar Arnfjörð Bjarmason writes:
>
>> Thanks, FWIW that's fine by me, and also if you want to drop this "fake"
>> patch of mine and replace it with something René came up with (I have
>> not yet read his 1-6 patches submitted on this topic, so maybe
Am 02.08.2018 um 22:01 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> Am 02.08.2018 um 18:54 schrieb Jeff King:
>>> PS I actually would have made the rule simply "does it begin with a
>>> '<'", which seems simpler still. If people
Parseopt wraps argument help strings in a pair of angular brackets by
default, to tell users that they need to replace it with an actual
value. This is useful in most cases, because most option arguments
are indeed single values of a certain type. The option
PARSE_OPT_LITERAL_ARGHELP needs to be
Wrap the placeholders in the option help string for -w in pairs of
angular brackets to document that users need to replace them with actual
numbers. Use the flag PARSE_OPT_LITERAL_ARGHELP to prevent parseopt
from adding another pair.
Signed-off-by: Rene Scharfe
---
builtin/shortlog.c | 6 --
Wrap each part of the argument help string in angular brackets to show
that users need to replace them with actual values. Do that explicitly
to balance the pairs nicely in the code and avoid confusing casual
readers. Add the flag PARSE_OPT_LITERAL_ARGHELP to keep parseopt from
adding another pai
Wrap both placeholders in the argument help string in angular brackets
to signal that users needs replace them with some actual value. Use the
flag PARSE_OPT_LITERAL_ARGHELP to prevent parseopt from adding another
pair.
Signed-off-by: Rene Scharfe
---
builtin/pack-objects.c | 4 ++--
1 file cha
Parseopt wraps arguments in a pair of angular brackets by default,
signifying that the user needs to replace it with a value of the
documented type. Remove the pairs from the option definitions to
duplication and confusion.
Signed-off-by: Rene Scharfe
---
builtin/difftool.c | 4 ++--
1 file cha
Don't translate the argument specification for --chmod; "+x" and "-x"
are the literal strings that the commands accept.
Separate alternatives using a pipe character instead of a slash, for
consistency.
Use the flag PARSE_OPT_LITERAL_ARGHELP to prevent parseopt from adding a
pair of angular bracke
Am 02.08.2018 um 18:54 schrieb Jeff King:
> PS I actually would have made the rule simply "does it begin with a
> '<'", which seems simpler still. If people accidentally write " forgetting to close their brackets, that is a bug under both the
> old and new behavior (just with slightly d
Am 02.08.2018 um 17:31 schrieb Junio C Hamano:
> René Scharfe writes:
>> diff --git a/parse-options.c b/parse-options.c
>> index 7db84227ab..fadfc6a833 100644
>> --- a/parse-options.c
>> +++ b/parse-options.c
>> @@ -660,7 +660,8 @@ int parse_options(int argc,
> the end result would balance out, by somebody who forgot the
> presence of PARSE_OPT_LITERAL_ARGHELP, which is the escape hatch
> mechanism designed to help such a case. We just should use the
> official escape hatch instead.
>
> Helped-by: René Scharfe
I didn't do anyt
Am 02.08.2018 um 17:06 schrieb René Scharfe:
> According to its manpage the option should rather be shown like this:
>
> --force-with-lease[=[:]]
>
> ... to indicate that all three forms are valid:
>
> --force-with-lease
> --force-with-lease=some_ref
&g
Am 02.08.2018 um 16:21 schrieb Ævar Arnfjörð Bjarmason:
>
> On Thu, Aug 02 2018, René Scharfe wrote:
>
>> Am 02.08.2018 um 00:31 schrieb Ævar Arnfjörð Bjarmason:
>>> But looking at this again it looks like this whole thing should just be
>>> replaced by:
>>
Am 02.08.2018 um 13:55 schrieb SZEDER Gábor:
> Let's add a bit of Makefile metaprogramming to generate finer-grained
> make targets applying one semantic patch to only a single source file,
> and specify these as dependencies of the targets applying one semantic
> patch to all source files. This w
Am 02.08.2018 um 00:31 schrieb Ævar Arnfjörð Bjarmason:
> But looking at this again it looks like this whole thing should just be
> replaced by:
>
> diff --git a/builtin/push.c b/builtin/push.c
> index 9cd8e8cd56..b8fa15c101 100644
> --- a/builtin/push.c
> +++ b/builtin/push.c
Thank you for the review!
Am 02.08.2018 um 04:56 schrieb Jonathan Nieder:
> René Scharfe wrote:
>
>> Subject: remote: clear string_list after use in mv()
>
> This subject line doesn't fully reflect the goodness of this change.
> How about something like:
>
>
Switch to the _DUP variant of string_list for remote_branches to allow
string_list_clear() to release the allocated memory at the end, and
actually call that function. Free the util pointer as well; it is
allocated in read_remote_branches().
NB: This string_list is empty until read_remote_branche
Am 31.07.2018 um 17:50 schrieb Jeff King:
> On Tue, Jul 31, 2018 at 11:03:17AM -0400, George Shammas wrote:
>
>> Bisecting around, this might be the commit that introduced the breakage.
>>
>> https://github.com/git/git/commit/d8febde
>>
>> I really hope that it hasn't been broken for 5 years and I
Am 31.07.2018 um 23:06 schrieb Junio C Hamano:
> Jeff King writes:
>
>> On Tue, Jul 31, 2018 at 01:23:04PM -0400, Jeff King wrote:
>> ...
>> So here it is fixed, and with a commit message. I'm not happy to omit a
>> regression test, but I actually couldn't come up with a minimal one that
>> tickl
Am 28.07.2018 um 00:32 schrieb Junio C Hamano:
> Josh Steadmon writes:
>
>> # Supporting HTTP remotes in "git archive"
>>
>> We would like to allow remote archiving from HTTP servers. There are a
>> few possible implementations to be discussed:
>>
>> ## Shallow clone to temporary repo
>>
>> This
Am 23.07.2018 um 15:50 schrieb SZEDER Gábor:
> Just a couple of minor Coccinelle-related improvements:
>
>- The first two patches are small cleanups.
>
>- The last three could make life perhaps just a tad bit easier for
> devs running 'make coccicheck'.
>
>
> SZEDER Gábor (5):
>
Am 19.06.2018 um 21:11 schrieb Jeff King:
> On Tue, Jun 19, 2018 at 08:50:16PM +0200, René Scharfe wrote:
>
>> Negation causes the whole non-matching line to match, with --column
>> reporting 1 or nothing in such a case, right? Or I think doing the
>> same when the oper
Am 19.06.2018 um 19:44 schrieb Taylor Blau:
> diff --git a/grep.c b/grep.c
> index f3329d82ed..a09935d8c5 100644
> --- a/grep.c
> +++ b/grep.c
> @@ -1257,8 +1257,8 @@ static int match_one_pattern(struct grep_pat *p, char
> *bol, char *eol,
> return hit;
> }
>
> -static int match_expr_eval
Am 19.06.2018 um 19:48 schrieb Jeff King:
> On Tue, Jun 19, 2018 at 07:33:39PM +0200, René Scharfe wrote:
>
>>> The key thing about this iteration is that it doesn't regress
>>> performance, because we always short-circuit where we used to. The other
>>> obv
Am 19.06.2018 um 19:44 schrieb Taylor Blau:
> On Tue, Jun 19, 2018 at 07:33:39PM +0200, René Scharfe wrote:
>> Am 19.06.2018 um 18:35 schrieb Jeff King:
>>> On Mon, Jun 18, 2018 at 06:43:01PM -0500, Taylor Blau wrote:
>> We could add an optimizer pass to reduce the number o
Am 19.06.2018 um 18:35 schrieb Jeff King:
> On Mon, Jun 18, 2018 at 06:43:01PM -0500, Taylor Blau wrote:
>> The notable case that it does _not_ cover is matching the following
>> line:
>>
>>a ... b
>>
>> with the following expression
>>
>>git grep --column -e b --or -e a
>>
>> This will pro
Am 10.06.2018 um 12:56 schrieb René Scharfe:
> Am 10.11.2017 um 20:05 schrieb Elijah Newren:
>> +static struct dir_rename_entry *check_dir_renamed(const char *path,
>> + struct hashmap *dir_renames) {
>> +char temp[PATH_MA
Am 10.11.2017 um 20:05 schrieb Elijah Newren:
> +static struct dir_rename_entry *check_dir_renamed(const char *path,
> + struct hashmap *dir_renames) {
> + char temp[PATH_MAX];
> + char *end;
> + struct dir_rename_entry *entry;
> +
> + s
Am 17.04.2018 um 23:30 schrieb Stefan Beller:
> +static void parse_color_fields(const char *s)
> +{
> + struct string_list l = STRING_LIST_INIT_DUP;
> + struct string_list_item *item;
> + enum { EXPECT_DATE, EXPECT_COLOR } next = EXPECT_COLOR;
> +
> + colorfield_nr = 0;
> +
> +
Am 07.06.2018 um 16:12 schrieb g...@jeffhostetler.com:
> Makefile| 2 +
> json-writer.c | 419
> json-writer.h | 113 +
> t/helper/test-json-writer.c | 572
>
Am 07.06.2018 um 16:12 schrieb g...@jeffhostetler.com:
> From: Jeff Hostetler
> +/*
> + * Add comma if we have already seen a member at this level.
> + */
> +static inline void maybe_add_comma(struct json_writer *jw)
> +{
> + if (!jw->open_stack.len)
> + return;
This is impossible
le encode such strings) in the future.
>
> The initial use for the json-writer routines is for generating telemetry
> data for executed Git commands. Later, we may want to use them in other
> commands, such as status.
>
> Helped-by: René Scharfe
> Helped-by:
Am 19.05.2018 um 03:57 schrieb Jeff King:
> These formatted integers should always fit into their
> 64-byte buffers. Let's use xsnprintf() to add an assertion
> that this is the case, which makes auditing for other
> unchecked snprintfs() easier.
How about this instead?
-- >8 --
Subject: [PATCH]
Am 14.05.2018 um 03:37 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> Storing integer values in pointers is a trick that seems to have worked
>> so far for fast-export. A portable way to avoid that trick without
>> requiring more memory would be to use a union.
&g
Am 12.05.2018 um 10:45 schrieb René Scharfe:
> Or we could roll our own custom hash map, as I mused in an earlier post.
> That would duplicate quite a bit of code; are there reusable pieces
> hidden within that could be extracted into common functions?
At least it would allow us to
Am 09.04.2018 um 03:42 schrieb Harald Nordgren:
> diff --git a/t/t5512-ls-remote.sh b/t/t5512-ls-remote.sh
> index 02106c922..83cd35c39 100755
> --- a/t/t5512-ls-remote.sh
> +++ b/t/t5512-ls-remote.sh
> @@ -170,14 +206,18 @@ test_expect_success 'overrides work between mixed
> transfer/upload-pack
Am 11.05.2018 um 19:42 schrieb Jeff King:
> On Fri, May 11, 2018 at 03:34:19PM +0200, Duy Nguyen wrote:
>
>> On Fri, May 11, 2018 at 03:11:46PM +0200, Duy Nguyen wrote:
>>> Back to fast-export, can we just allocate a new int on heap and point
>>> it there? Allocating small pieces becomes quite che
Am 10.05.2018 um 12:51 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> The standard says about uintptr_t that "any valid pointer to void can
>> be converted to this type, then converted back to pointer to void, and
>> the result will compare equal to th
Am 09.05.2018 um 23:06 schrieb René Scharfe:
> Clang 6 reports the following warning, which is turned into an error in a
> DEVELOPER build:
>
> builtin/fast-export.c:162:28: error: performing pointer arithmetic on a
> null pointer has undefined behavior [-Werror,-Wnull-poi
Am 10.05.2018 um 02:04 schrieb Junio C Hamano:
> Taylor Blau writes:
>
>> This check we should retain and change the wording to mention '--and',
>> '--or', and '--not' specifically.
>
> Why are these problematic in the first place? If I said
>
> $ git grep -e first --and -e these
> $
Clang 6 reports the following warning, which is turned into an error in a
DEVELOPER build:
builtin/fast-export.c:162:28: error: performing pointer arithmetic on a
null pointer has undefined behavior [-Werror,-Wnull-pointer-arithmetic]
return ((uint32_t *)NULL) + mark;
Am 05.05.2018 um 04:42 schrieb Taylor Blau:
> When calling match_line(), callers presently cannot determine the
> relative offset of the match because match_line() discards the
> 'regmatch_t' that contains this information.
>
> Instead, teach match_line() to take in a 'regmatch_t *' so that caller
Am 21.04.2018 um 06:14 schrieb Junio C Hamano:
> Junio C Hamano writes:
>
>> Taylor Blau writes:
>>
>>> This commit teaches 'git-grep(1)' a new option, '--column-number'. This
>>> ...
>>> +`columnnumber`;;
>>> + column number prefix (when using `-m`)
>>
>> Is there other people's tool (preferr
Am 10.04.2018 um 00:45 schrieb Stefan Beller:
> By making the oidmap a pointer, we eliminate the need for
> the global boolean variable 'replace_object_prepared'.
>
> Signed-off-by: Stefan Beller
> ---
> object-store.h | 2 +-
> replace-object.c | 16 +---
> 2 files changed, 10
Am 07.04.2018 um 01:21 schrieb Stefan Beller:
> This applies on top of 464416a2eaadf84d2bfdf795007863d03b222b7c
> (sb/packfiles-in-repository).
> It is also available at
> https://github.com/stefanbeller/git/tree/object-store-3
This series conflicts with 1731a1e239 (replace_object: convert struct
Am 30.03.2018 um 07:28 schrieb Taylor Blau:
> diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
> index e09ed5d7d..9956b03f7 100644
> --- a/Documentation/git-config.txt
> +++ b/Documentation/git-config.txt
> @@ -160,30 +158,34 @@ See also <>.
> --list::
> List all var
Am 28.03.2018 um 23:37 schrieb Stefan Beller:
>> This looks nicer here in the script, but doesn't test exactly what users
>> type most of the time, I suppose.
>>
>> So how about this?
>
> Looks good to me, though I had a nagging feeling at first that the
> regex could be made more concise.
> Why d
Am 28.03.2018 um 22:21 schrieb Eric Sunshine:
> On Wed, Mar 28, 2018 at 4:08 PM, Stefan Beller wrote:
>> On Wed, Mar 28, 2018 at 11:57 AM, Eric Sunshine
>> wrote:
+test_expect_success 'moving the submodule does not break the
superproject' '
+ (
+ cd addte
Am 25.03.2018 um 18:19 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> Replace the custom binary search in unique_in_pack() with a call to
>> bsearch_pack(). This reduces code duplication and makes use of the
>> fan-out table of packs.
>>
>> Signed-off
Signed-off-by: Rene Scharfe
---
That leak was introduced by c0c578b33c (unpack-trees: batch fetching of
missing blobs).
unpack-trees.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/unpack-trees.c b/unpack-trees.c
index d5685891a5..e73745051e 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
Patch generated with Coccinelle and contrib/coccinelle/object_id.cocci.
Signed-off-by: Rene Scharfe
---
This is a belated follow-up to f0a6068a9f (bisect: debug: convert struct
object to object_id).
bisect.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/bisect.c b/bise
Patch generated with Coccinelle and contrib/coccinelle/strbuf.cocci.
Signed-off-by: Rene Scharfe
---
That line was added by e73dd78699 (run-command.c: introduce
trace_run_command()).
run-command.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/run-command.c b/run-command.c
Am 25.03.2018 um 11:50 schrieb Jeremy Feusi:
>
> Hmm... That's weird. I can reproduce it on 3 independant systems with
> versions 2.16.2 up, although it does not work with version 2.11.0.
> Anyway, I figured out how to reproduce this bug. It is caused when a
> submodule is added and then the direc
Am 24.03.2018 um 18:42 schrieb Jeremy Feusi:
> Hi,
> While bootstrapping a gnu repository I noticed that git segfaulted when
> called as "git submodule status". After compiling git with address
> sanitizer and minimizing the directory I finally narrowed it down to the
> files which I have attached
Replace the custom binary search in unique_in_pack() with a call to
bsearch_pack(). This reduces code duplication and makes use of the
fan-out table of packs.
Signed-off-by: Rene Scharfe
---
This is basically the same replacement as done by patch 3. Speed is
less of a concern here -- at least I
Am 23.03.2018 um 20:55 schrieb Jeff Hostetler:
>>> +struct json_writer_level
>>> +{
>>> + unsigned level_is_array : 1;
>>> + unsigned level_is_empty : 1;
>>> +};
>>> +
>>> +struct json_writer
>>> +{
>>> + struct json_writer_level *levels;
>>> + int nr, alloc;
>>> + struct strbuf json
Am 21.03.2018 um 20:28 schrieb g...@jeffhostetler.com:
> From: Jeff Hostetler
>
> Add basic routines to generate data in JSON format.
>
> Signed-off-by: Jeff Hostetler
> ---
> Makefile| 2 +
> json-writer.c | 321 +
> json-
Am 08.03.2018 um 13:06 schrieb Takuto Ikuta:
> In repository having large number of refs, lstat for non-existing loose
> objects makes `git fetch` slow.
>
> This patch stores existing loose objects in hashmap beforehand and use
> it to check existence instead of using lstat.
>
> With this patch,
Am 07.03.2018 um 10:36 schrieb Eric Sunshine:
> On Tue, Mar 6, 2018 at 6:05 PM, Jun Wu wrote:
>> Excerpts from Eric Sunshine's message of 2018-03-06 14:23:46 -0500:
>>> On Tue, Mar 6, 2018 at 6:53 AM, Jun Wu wrote:
+ printf "x%.0s" {1..934} >>d # pad common suffix to 1024 bytes
>>>
>>> The
Am 27.02.2018 um 02:18 schrieb Alan Gage:
> Hello, I recently noticed a bug involving GitBash and Python. I was
> running a function that would post the system time once every second
> using a while loop but the text was only sent after the while loop
> ended due to a timer I had set. Essesntially,
9ba95ed23c (perf/run: update get_var_from_env_or_config() for
subsections) stopped setting a default value for GIT_PERF_REPEAT_COUNT
if no perf config file is present, because get_var_from_env_or_config
returns early in that case.
Fix it by setting the default value after calling this function. I
Am 24.02.2018 um 03:24 schrieb Ramsay Jones:
> diff --git a/commit-graph.c b/commit-graph.c
> index fc5ee7e99..c2f443436 100644
> --- a/commit-graph.c
> +++ b/commit-graph.c
> @@ -45,7 +45,7 @@ char *get_graph_latest_filename(const char *obj_dir)
> {
> struct strbuf fname = STRBUF_INIT;
>
Am 23.02.2018 um 23:17 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> +#define IGNORE_ERROR(expr) do { int e_ = errno; expr; errno = e_; } while
>> (0)
>
> The macro certainly is a cute idea, but ...
>
>> @@ -391,7 +393,7 @@ ssize_t strbuf_read(struct st
Am 23.02.2018 um 08:00 schrieb Jeff King:
> On Fri, Feb 23, 2018 at 01:49:52AM -0500, Jeff King wrote:
> Subject: [PATCH] strbuf_read_file(): preserve errno across close() call
>
> If we encounter a read error, the user may want to report it
> by looking at errno. However, our close() call may clo
Reduce code duplication by factoring out a function that reads an entire
file into a strbuf, or reports errors on stderr if something goes wrong.
Signed-off-by: Rene Scharfe
---
The difference to using strbuf_read_file() is more detailed error
messages for open(2) failures. But I don't know if w
Am 12.02.2018 um 22:48 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> Am 12.02.2018 um 22:04 schrieb Junio C Hamano:
>>> Stefan Beller writes:
>>>
>>>> I thought it may be a helpful
>>>> for merging this series with the rest of the e
[removed rene.scha...@lsrfire.ath.cx from cc:; I lost that domain a few
years ago. Thanks for the heads-up, Stefan!]
Am 12.02.2018 um 20:00 schrieb Stefan Beller:
> On Fri, Feb 9, 2018 at 2:09 PM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> Patch generated by
>>>
>>> 2. Applying th
Am 12.02.2018 um 22:04 schrieb Junio C Hamano:
> Stefan Beller writes:
>
>> I thought it may be a helpful
>> for merging this series with the rest of the evolved code base which
>> may make use of one of the converted functions. So instead of fixing
>> that new instance manually, cocinelle could
In check_ignore(), the first pathspec item determines the dtype for any
subsequent ones. That means that a pathspec matching a regular file can
prevent following pathspecs from matching directories, which makes no
sense. Fix that by determining the dtype for each pathspec separately,
by passing t
Am 02.02.2018 um 23:36 schrieb Jonathan Tan:
> Subsequent patches will introduce file formats that make use of a fanout
> array and a sorted table containing hashes, just like packfiles.
> Refactor the hash search in packfile.c into its own function, so that
> those patches can make use of it as we
Am 02.02.2018 um 15:34 schrieb SZEDER Gábor:
> On Thu, Feb 1, 2018 at 7:56 PM, René Scharfe wrote:
>> 353d84c537 (coccicheck: make transformation for strbuf_addf(sb, "...")
>> more precise) added a check to avoid transforming calls with format
>> strings which conta
353d84c537 (coccicheck: make transformation for strbuf_addf(sb, "...")
more precise) added a check to avoid transforming calls with format
strings which contain percent signs, as that would change the result.
It uses embedded Python code for that. Simplify this rule by using the
regular expression
Am 20.01.2018 um 23:24 schrieb Gargi Sharma:
> On Sat, Jan 20, 2018 at 1:02 AM, Eric Wong wrote:
>> Gargi Sharma wrote:
>>> --- a/list.h
>>> +++ b/list.h
>>> @@ -93,6 +93,13 @@ static inline void list_move(struct list_head *elem,
>>> struct list_head *head)
>>>list_add(elem, head);
>>>
Am 20.01.2018 um 14:44 schrieb Randall S. Becker:
> On January 20, 2018 7:31 AM, René Scharfe wrote:
>> Am 19.01.2018 um 18:34 schrieb randall.s.bec...@rogers.com:
>>> From: "Randall S. Becker"
>>>
>>> * Makefile: Add TAR_EXTRACT_OPTIONS to allow
Am 19.01.2018 um 18:34 schrieb randall.s.bec...@rogers.com:
> From: "Randall S. Becker"
>
> * Makefile: Add TAR_EXTRACT_OPTIONS to allow platform options to be
>specified if needed. The default is xof.
>
> Signed-off-by: Randall S. Becker
> ---
> Makefile | 6 +-
> 1 file changed, 5
Am 18.01.2018 um 23:40 schrieb SZEDER Gábor:
> On Thu, Jan 18, 2018 at 10:40 PM, René Scharfe wrote:
>> Am 16.01.2018 um 18:11 schrieb SZEDER Gábor:
>>> Unfortunately, most of the changes coming from 'strbuf.cocci' don't
>>> make any sense, they ap
There's a rule in strbuf.cocci for converting trivial uses of
strbuf_addf() to strbuf_addstr() in order to simplify the code and
improve performance a bit. Coccinelle 1.0.0~rc19.deb-3 on Travis CI
lets the "%s" in that rule match format strings like "%d" as well for
some reason, though, leading to
Am 16.01.2018 um 18:11 schrieb SZEDER Gábor:
> Unfortunately, most of the changes coming from 'strbuf.cocci' don't
> make any sense, they appear to be the mis-application of the "use
> strbuf_addstr() instead of strbuf_addf() to add a single string" rule:
>
>- strbuf_addf(&sb_repo,
Call strbuf_add_unique_abbrev() to add an abbreviated hash to a strbuf
instead of taking a detour through find_unique_abbrev() and its static
buffer. This is shorter and a bit more efficient.
Patch generated by Coccinelle (and contrib/coccinelle/strbuf.cocci).
Signed-off-by: Rene Scharfe
---
Th
Am 12.01.2018 um 20:52 schrieb Randall S. Becker:
> On a related too many warnings subject, hashmap.h has a variable
> unused (void *item). Is that addressed soon? If not, I can deal with
> it.
Here are the code lines containing the variable in question:
void *item;
while ((item =
Am 10.01.2018 um 08:58 schrieb Jeff King:
> On Mon, Dec 25, 2017 at 06:44:58PM +0100, René Scharfe wrote:
>
>> Add a function for clearing the commit marks of all in-core commit
>> objects. It's similar to clear_object_flags(), but more precise, since
>> it leaves
Am 10.01.2018 um 09:07 schrieb Jeff King:
> On Mon, Dec 25, 2017 at 06:45:36PM +0100, René Scharfe wrote:
>
>> The leak_pending flag is so awkward to use that multiple comments had to
>> be added around each occurrence. We only use it for remembering the
>> commits whos
Hello Dscho,
Am 08.01.2018 um 21:45 schrieb Johannes Schindelin:
> Isn't this identical to
> https://public-inbox.org/git/20180103184852.27271-1-ava...@gmail.com/ ?
yes, indeed, thanks. So here's an upvote for Ævar's patch then. :)
(I should have sent it earlier, but was not fully convinced it
7c117184d7 (bisect: fix off-by-one error in `best_bisection_sorted()`)
fixed an off-by-one error, plugged a memory leak and removed a NULL
check. However, the pointer p *is* actually NULL if an empty list is
passed to the function. Let's add the check back for safety. Bisecting
nothing doesn't m
Am 04.01.2018 um 19:22 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> I don't know if it's a good idea, but perhaps we don't even need a new
>> option. We could change how pathspecs of untracked files are handled:
>> Instead of aborting we could inc
Am 04.01.2018 um 03:25 schrieb suzuki toshiya:
> Taking a glance on parse-options.h, I could not find the
> existing class collecting the operands as an array (or
> linked list) from multiple "--xxx=yyy" options. Similar
> things might be the collecting the pathnames to pathspec
> structure. Should
[replying only to the list because emails to per...@pluto.rain.com
are rejected by my mail server with the following error message:
"Requested action not taken: mailbox unavailable
invalid DNS MX or A/ resource record."]
Am 02.01.2018 um 01:32 schrieb Perry Hutchison:
> Ren?? Scharfe wrot
Am 02.01.2018 um 07:58 schrieb suzuki toshiya:
> Dear René ,
>
> René Scharfe wrote:
>> Am 29.12.2017 um 15:05 schrieb suzuki toshiya:
>>> The ownership of files created by git-archive is always
>>> root:root. Add --owner and --group options which work
>>
Am 29.12.2017 um 15:05 schrieb suzuki toshiya:
> The ownership of files created by git-archive is always
> root:root. Add --owner and --group options which work
> like the GNU tar equivalent to allow overriding these
> defaults.
In which situations do you use the new options?
(The sender would ne
Signed-off-by: Rene Scharfe
---
commit.c | 14 --
commit.h | 1 -
2 files changed, 15 deletions(-)
diff --git a/commit.c b/commit.c
index 9edc12f338..ff51c9f34a 100644
--- a/commit.c
+++ b/commit.c
@@ -559,20 +559,6 @@ void clear_commit_marks(struct commit *commit, unsigned
int mar
Signed-off-by: Rene Scharfe
---
revision.c | 3 +--
revision.h | 12
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/revision.c b/revision.c
index f6a3da5cd9..7239315de9 100644
--- a/revision.c
+++ b/revision.c
@@ -2860,8 +2860,7 @@ int prepare_revision_walk(struct re
The leak_pending flag is so awkward to use that multiple comments had to
be added around each occurrence. We only use it for remembering the
commits whose marks we have to clear after checking if the old HEAD is
detached. This is easy, though: We need to do that for the old commit,
the new one --
The leak_pending flag is so awkward to use that multiple comments had to
be added around each occurrence. We only use it for remembering the
commits whose marks we have to clear after checking if all of the good
ones are ancestors of the bad one. This is easy, though: We need to do
that for the b
The leak_pending flag is so awkward to use that multiple comments had to
be added around each occurrence. We use it for remembering the
prerequisites for the bundle. That is easy, though: We have the
ref_list named "prerequisites" in the header for just that purpose.
Use this original list of pr
Add a function for clearing the commit marks of all in-core commit
objects. It's similar to clear_object_flags(), but more precise, since
it leaves the other object types alone. It still has to iterate through
them, though.
Signed-off-by: Rene Scharfe
---
object.c | 11 +++
object.h |
Signed-off-by: Rene Scharfe
---
ref-filter.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/ref-filter.c b/ref-filter.c
index 3f9161707e..f9e25aea7a 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1995,8 +1995,7 @@ static void do_merge_filter(struct ref_filter_cbdata
*ref
Pass the entries of the commit array directly to clear_commit_marks_1()
instead of adding them to a commit_list first. The function clears the
commit and any first parent without allocation; only higher numbered
parents are added to a list for later treatment. This change extends
that optimizatio
201 - 300 of 1338 matches
Mail list logo
