Re: [PATCH 2/2] commit-template: distinguish status information unconditionally

On Fri, 2017-06-30 at 07:52 -0700, Junio C Hamano wrote: > Thanks, both looks good.  Will queue. You're welcome :)

[PATCH 05/10] convert/sub-process: drop cast to hashmap_cmp_fn

Signed-off-by: Stefan Beller --- convert.c | 3 +-- sub-process.c | 7 +-- sub-process.h | 4 ++-- 3 files changed, 8 insertions(+), 6 deletions(-) diff --git a/convert.c b/convert.c index deaf0ba7b3..04966c723c 100644 --- a/convert.c +++ b/convert.c @@ -583,8 +583,7 @@ static int apply_

[PATCH 07/10] remote.c: drop hashmap_cmp_fn cast

Signed-off-by: Stefan Beller --- remote.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/remote.c b/remote.c index 60d0043921..3efa358558 100644 --- a/remote.c +++ b/remote.c @@ -134,10 +134,14 @@ struct remotes_hash_key { }; static int remotes_hash_cmp(const

[PATCH 06/10] patch-ids.c: drop hashmap_cmp_fn cast

Signed-off-by: Stefan Beller --- patch-ids.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/patch-ids.c b/patch-ids.c index b4166b0f38..9ea523984b 100644 --- a/patch-ids.c +++ b/patch-ids.c @@ -35,11 +35,16 @@ int commit_patch_id(struct commit *commit, struct

[PATCH 10/10] t/helper/test-hashmap: use custom data instead of duplicate cmp functions

With the new field that is passed to the compare function, we can pass through flags there instead of having multiple compare functions. Also drop the cast to hashmap_cmp_fn. Signed-off-by: Stefan Beller --- t/helper/test-hashmap.c | 34 -- 1 file changed, 16 inse

[PATCH 08/10] submodule-config.c: drop hashmap_cmp_fn cast

Signed-off-by: Stefan Beller --- submodule-config.c | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/submodule-config.c b/submodule-config.c index 0e1126183d..edc8dd04b6 100644 --- a/submodule-config.c +++ b/submodule-config.c @@ -35,27 +35,33 @@ static stru

[PATCH 03/10] builtin/describe: drop hashmap_cmp_fn cast

Signed-off-by: Stefan Beller --- builtin/describe.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/builtin/describe.c b/builtin/describe.c index 8868f00ed0..f2f2edf935 100644 --- a/builtin/describe.c +++ b/builtin/describe.c @@ -55,10 +55,13 @@ static const char *pri

[PATCH 09/10] name-hash.c: drop hashmap_cmp_fn cast

Signed-off-by: Stefan Beller --- name-hash.c | 22 +- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/name-hash.c b/name-hash.c index 0e10f3eab8..bd8dc7a6a7 100644 --- a/name-hash.c +++ b/name-hash.c @@ -17,10 +17,14 @@ struct dir_entry { }; static int dir_e

[PATCH 00/10] Friday night special: hash map cleanup

This goes on top of sb/hashmap-customize-comparison. No functional impact but a pure cleanup series: No casts to hashmap_cmp_fn in the whole code base any more. This revealed another interesting thing, which is not a bug per se: The const correctness of hashmap_cmp_fn as it requires all its void p

[PATCH 01/10] attr.c: drop hashmap_cmp_fn cast

MAke the code more readable and less error prone by avoiding the cast of the compare function pointer in hashmap_init, but instead have the correctly named void pointers to casted to the specific data structure. Signed-off-by: Stefan Beller --- attr.c | 12 +++- 1 file changed, 7 inserti

[PATCH 04/10] config.c: drop hashmap_cmp_fn cast

Signed-off-by: Stefan Beller --- config.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/config.c b/config.c index 4a31e31ac3..30ff700629 100644 --- a/config.c +++ b/config.c @@ -1754,17 +1754,19 @@ static int configset_add_value(struct config_set *cs, const char

[PATCH 02/10] builtin/difftool.c: drop hashmap_cmp_fn cast

Signed-off-by: Stefan Beller --- builtin/difftool.c | 37 ++--- 1 file changed, 22 insertions(+), 15 deletions(-) diff --git a/builtin/difftool.c b/builtin/difftool.c index a1a26ba891..8864d846f8 100644 --- a/builtin/difftool.c +++ b/builtin/difftool.c @@ -131,10

Re: [GSoC][PATCH 5/5 v3] submodule: port submodule subcommand 'sync' from shell to C

Prathamesh Chavan writes: > +static void sync_submodule(const struct cache_entry *list_item, void > *cb_data) > +{ > + struct sync_cb *info = cb_data; > + const struct submodule *sub; > + char *sub_key, *remote_key; > + char *sub_origin_url, *super_config_url, *displaypath; > +

Re: [GSoC][PATCH 4/5 v3] submodule: port submodule subcommand 'status' from shell to C

Prathamesh Chavan writes: > + argv_array_pushl(&diff_files_args, "diff-files", > + "--ignore-submodules=dirty", "--quiet", "--", > + list_item->name, NULL); > + > + if (!cmd_diff_files(diff_files_args.argc, diff_files_args.argv, > +

Re: [GSoC][PATCH 3/5 v3] submodule: port set_name_rev() from shell to C

Prathamesh Chavan writes: > Function set_name_rev() is ported from git-submodule to the > submodule--helper builtin. The function get_name_rev() generates the > value of the revision name as required, and the function > print_name_rev() handles the formating and printing of the obtained > revisio

Re: [RFC 0/4] Implementation of fetch-blobs and fetch-refs

Sorry for not paying attention to this patch set earlier. I missed (and might still miss) the big picture(tm) here. This is because http://public-inbox.org/git/ffd92ad9-39fe-c76b-178d-6e3d6a425...@google.com/ seemed to be specific for big binary files, but ... On Mon, Apr 10, 2017 at 1:46 PM, Jona

Re: [GSoC][PATCH 1/5 v3] submodule--helper: introduce get_submodule_displaypath()

Prathamesh Chavan writes: > Introduce function get_submodule_displaypath() to replace the code > occurring in submodule_init() for generating displaypath of the > submodule with a call to it. > > This new function will also be used in other parts of the system > in later patches. > > Mentored-by:

Re: speeding up git pull from a busy gerrit instance over a slow link?

On Fri, Jun 30, 2017 at 5:28 AM, Noel Grandin wrote: > Hi > > I'm running git version 2.13.1 on Ubuntu 16.04 (x64) > > I'm connecting over a very slow (international link) to a very busy gerrit > server (gerrit.libreoffice.org) using ssh. > Ping types are on the order of 200ms. > > Using GIT_TRACE

Re: speeding up git pull from a busy gerrit instance over a slow link?

On Fri, 30 Jun 2017 14:28:15 +0200 Noel Grandin wrote: > - > snippet of packet trace > --- > > 14:20:45.705091 pkt-line.c:80 packet:fetch< > c5b026801c729ab37e2af6a610f31ca2e28b51fe > refs/changes/99/29099/2 > 14:20:45.705093 pkt-line.c:80

What's cooking in git.git (Jun 2017, #09; Fri, 30)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. You can find the changes described

Re: [PATCHv2 00/25] Reroll of sb/diff-color-moved.

This (obviously) passes the failing tests. I should have spotted why the rebase of the previous one did not work myself before bugging you X-<. Thanks. Queued.

Re: [PATCHv2 22/25] diff.c: color moved lines differently

Stefan Beller writes: > On Fri, Jun 30, 2017 at 2:11 PM, Junio C Hamano wrote: >>> + return (int)' '; >> >> Do we need a cast here? > > No, I figured it is good to have it here explicitly, though. > We can drop that if you have strong preferences one way or another. I was merely won

Re: [PATCH v9 0/7] convert: add "status=delayed" to filter process protocol

Will queue. I personally feel that this is polished enough for 'next'. Thanks.

Re: [PATCHv2 22/25] diff.c: color moved lines differently

On Fri, Jun 30, 2017 at 2:11 PM, Junio C Hamano wrote: >> + return (int)' '; > > Do we need a cast here? No, I figured it is good to have it here explicitly, though. We can drop that if you have strong preferences one way or another. > >> +static unsigned get_string_hash(struct emitt

Re: [PATCHv2 22/25] diff.c: color moved lines differently

Stefan Beller writes: > +static int next_byte(const char **cp, const char **endp, > + const struct diff_options *diffopt) > +{ > + int retval; > + > + if (*cp > *endp) > + return -1; > + > + if (DIFF_XDL_TST(diffopt, IGNORE_WHITESPACE_CHANGE)) { > +

[PATCHv2 04/25] diff.c: introduce emit_diff_symbol

In a later patch we want to buffer all output before emitting it as a new feature ("markup moved lines") conceptually cannot be implemented in a single pass over the output. There are different approaches to buffer all output such as: * Buffering on the char level, i.e. we'd have a char[] which wo

[PATCHv2 08/25] diff.c: migrate emit_line_checked to use emit_diff_symbol

Add a new flags field to emit_diff_symbol, that will be used by context lines for: * white space rules that are applicable (The first 12 bits) Take a note in cahe.c as well, when this ws rules are extended we have to fix the bits in the flags field. * how the rules are evaluated (actually this

[PATCHv2 16/25] diff.c: convert emit_binary_diff_body to use emit_diff_symbol

Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 63 ++- 1 file changed, 46 insertions(+), 17 deletions(-) diff --git a/diff.c b/diff.c index 48f719fb07..f5a14359ae 100644 --- a/diff.c +++ b/diff.c @@ -561,6 +561

[PATCHv2 22/25] diff.c: color moved lines differently

When a patch consists mostly of moving blocks of code around, it can be quite tedious to ensure that the blocks are moved verbatim, and not undesirably modified in the move. To that end, color blocks that are moved within the same patch differently. For example (OM, del, add, and NM are different c

[PATCHv2 23/25] diff.c: color moved lines differently, plain mode

Add the 'plain' mode for move detection of code. This omits the checking for adjacent blocks, so it is not as useful. If you have a lot of the same blocks moved in the same patch, the 'Zebra' would end up slow as it is O(n^2) (n is number of same blocks). So this may be useful there and is generall

[PATCHv2 11/25] diff.c: emit_diff_symbol learns DIFF_SYMBOL_FILEPAIR_{PLUS, MINUS}

We have to use fprintf instead of emit_line, because we want to emit the tab after the color. This is important for ancient versions of gnu patch AFAICT, although we probably do not want to feed colored output to the patch utility, such that it would not matter if the trailing tab is colored. Keep

[PATCHv2 10/25] diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_INCOMPLETE

The context marker use the exact same output pattern, so reuse it. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/diff.c b/diff.c index 85bfd9310d..b2b2a19fcf 100644 --- a/diff.c +++ b/diff.c @@ -56

[PATCHv2 03/25] diff.c: factor out diff_flush_patch_all_file_pairs

In a later patch we want to do more things before and after all filepairs are flushed. So factor flushing out all file pairs into its own function that the new code can be plugged in easily. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 17 - 1 file cha

[PATCHv2 25/25] diff: document the new --color-moved setting

Signed-off-by: Stefan Beller --- Documentation/config.txt | 15 +-- Documentation/diff-options.txt | 36 2 files changed, 49 insertions(+), 2 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 06898a7498..743

[PATCHv2 19/25] diff.c: emit_diff_symbol learns about DIFF_SYMBOL_STAT_SEP

Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/diff.c b/diff.c index e0d39d04da..5a9c55736d 100644 --- a/diff.c +++ b/diff.c @@ -571,6 +571,7 @@ enum diff_symbol { DIFF_SYMBOL_STATS_SUMM

[PATCHv2 24/25] diff.c: add dimming to moved line detection

Any lines inside a moved block of code are not interesting. Boundaries of blocks are only interesting if they are next to another block of moved code. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- color.h| 2 + diff.c | 132

[PATCHv2 21/25] diff.c: buffer all output if asked to

Introduce a new option 'emitted_symbols' in the struct diff_options which controls whether all output is buffered up until all output is available. It is set internally in diff.c when necessary. We'll have a new struct 'emitted_string' in diff.c which will be used to buffer each line. The emitted

[PATCHv2 14/25] diff.c: emit_diff_symbol learns DIFF_SYMBOL_REWRITE_DIFF

Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 35 +-- 1 file changed, 21 insertions(+), 14 deletions(-) diff --git a/diff.c b/diff.c index 1d0f8b509f..5c428e02b6 100644 --- a/diff.c +++ b/diff.c @@ -561,6 +561,7 @@ static void emit_line(

[PATCHv2 12/25] diff.c: emit_diff_symbol learns DIFF_SYMBOL_HEADER

The header is constructed lazily including line breaks, so just emit the raw string as is. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 28 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/diff.c b/diff.c index 49b45fef29..78

[PATCHv2 09/25] diff.c: emit_diff_symbol learns DIFF_SYMBOL_WORDS[_PORCELAIN]

Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 42 ++ 1 file changed, 26 insertions(+), 16 deletions(-) diff --git a/diff.c b/diff.c index e5430d56da..85bfd9310d 100644 --- a/diff.c +++ b/diff.c @@ -561,6 +561,8 @@ static void emi

[PATCHv2 17/25] diff.c: convert show_stats to use emit_diff_symbol

We call print_stat_summary from builtin/apply, so we still need the version with a file pointer, so introduce print_stat_summary_0 that uses emit_string machinery and keep print_stat_summary with the same arguments around. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c |

[PATCHv2 18/25] diff.c: convert word diffing to use emit_diff_symbol

The word diffing is not line oriented and would need some serious effort to be transformed into a line oriented approach, so just go with a symbol DIFF_SYMBOL_WORD_DIFF that is a partial line. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 79 +++

[PATCHv2 13/25] diff.c: emit_diff_symbol learns about DIFF_SYMBOL_BINARY_FILES

we could save a little bit of memory when buffering in a later mode by just passing the inner part ("%s and %s", file1, file 2), but those a just a few bytes, so instead let's reuse the implementation from DIFF_SYMBOL_HEADER and keep the whole line around. Signed-off-by: Stefan Beller Signed-off-

[PATCHv2 15/25] submodule.c: migrate diff output to use emit_diff_symbol

As the submodule process is no longer attached to the same file pointer 'o->file' as the superprojects process, there is a different result in color.c::check_auto_color. That is why we need to pass coloring explicitly, such that the submodule coloring decision will be made by the child process proc

[PATCHv2 20/25] diff.c: emit_diff_symbol learns about DIFF_SYMBOL_SUMMARY

Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 71 ++ 1 file changed, 41 insertions(+), 30 deletions(-) diff --git a/diff.c b/diff.c index 5a9c55736d..2db0d7c0f5 100644 --- a/diff.c +++ b/diff.c @@ -572,6 +

[PATCHv2 02/25] diff.c: move line ending check into emit_hunk_header

The emit_hunk_header() function is responsible for assembling a hunk header and calling emit_line() to send the hunk header to the output file. Its only caller fn_out_consume() needs to prepare for a case where the function emits an incomplete line and add the terminating LF. Instead make sure em

[PATCHv2 07/25] diff.c: emit_diff_symbol learns DIFF_SYMBOL_NO_LF_EOF

Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/diff.c b/diff.c index 6e48a129ed..488096b757 100644 --- a/diff.c +++ b/diff.c @@ -561,6 +561,7 @@ static void emit_line(struct diff_optio

[PATCHv2 01/25] diff.c: readability fix

We already have dereferenced 'p->two' into a local variable 'two'. Use that. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/diff.c b/diff.c index 00b4c86698..2874dfc6fc 100644 --- a/diff.c +++ b/diff.

[PATCHv2 05/25] diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_MARKER

Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/diff.c b/diff.c index 4637368d59..75b996c4cf 100644 --- a/diff.c +++ b/diff.c @@ -561,13 +561,20 @@ static void emit_line(struct diff_options *o, co

[PATCHv2 06/25] diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_FRAGINFO

Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/diff.c b/diff.c index 75b996c4cf..6e48a129ed 100644 --- a/diff.c +++ b/diff.c @@ -561,6 +561,7 @@ static void emit_line(struct diff_options *o, const

[PATCHv2 00/25] Reroll of sb/diff-color-moved.

v2: * on top of the new hashmap patches[3]. It compiles when put on older versions of the hashmap series, as the hashmap compare function just swapped void pointers in the definition. * better documentation, Thanks Simon! ... If there are fewer than 3 adjacent moved lines, they are

Re: [PATCH v8 6/6] convert: add "status=delayed" to filter process protocol

> On 30 Jun 2017, at 20:19, Junio C Hamano wrote: > > Lars Schneider writes: > >>> On 29 Jun 2017, at 20:34, Junio C Hamano wrote: >>> >>> You seem to have squashed an unrelated "table-driven" clean-up into >>> this step. While I think the end result looks good, I would have >>> liked to se

[PATCH v9 2/7] t0021: make debug log file name configurable

The "rot13-filter.pl" helper wrote its debug logs always to "rot13-filter.log". Make this configurable by defining the log file as first parameter of "rot13-filter.pl". This is useful if "rot13-filter.pl" is configured multiple times similar to the subsequent patch 'convert: add "status=delayed" t

[PATCH v9 6/7] convert: refactor capabilities negotiation

The code to negotiate long running filter capabilities was very repetitive for new capabilities. Replace the repetitive conditional statements with a table-driven approach. This is useful for the subsequent patch 'convert: add "status=delayed" to filter process protocol'. Suggested-by: Junio C Ham

[PATCH v9 7/7] convert: add "status=delayed" to filter process protocol

Some `clean` / `smudge` filters may require a significant amount of time to process a single blob (e.g. the Git LFS smudge filter might perform network requests). During this process the Git checkout operation is blocked and Git needs to wait until the filter is done to continue with the checkout.

[PATCH v9 5/7] convert: move multiple file filter error handling to separate function

Refactoring the filter error handling is useful for the subsequent patch 'convert: add "status=delayed" to filter process protocol'. In addition, replace the parentheses around the empty "if" block with a single semicolon to adhere to the Git style guide. Signed-off-by: Lars Schneider --- conve

[PATCH v9 4/7] convert: put the flags field before the flag itself for consistent style

Suggested-by: Jeff King Signed-off-by: Lars Schneider --- convert.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/convert.c b/convert.c index f1e168bc30..9907e3b9ba 100644 --- a/convert.c +++ b/convert.c @@ -597,12 +597,12 @@ static int apply_multi_file_filter(co

[PATCH v9 3/7] t0021: write "OUT " only on success

"rot13-filter.pl" always writes "OUT " to the debug log at the end of a response. This works perfectly for the existing responses "abort", "error", and "success". A new response "delayed", that will be introduced in a subsequent patch, accepts the input without giving the filtered result right awa

[PATCH v9 0/7] convert: add "status=delayed" to filter process protocol

Hi, here is the 9th iteration of my "status delayed" topic. I think that might be the final one :-) Patch 1 to 3 are minor t0021 test adjustments. Patch 4 to 6 are convert refactorings to prepare the new feature. Patch 7 is the new feature. ### Changes since v7: * extracted capabilities negotiat

[PATCH v9 1/7] t0021: keep filter log files on comparison

The filter log files are modified on comparison. That might be unexpected by the caller. It would be even undesirable if the caller wants to reuse the original log files. Address these issues by using temp files for modifications. This is useful for the subsequent patch 'convert: add "status=delay

Re: [PATCH 25/25] diff: document the new --color-moved setting

On Fri, Jun 30, 2017 at 1:31 PM, Simon Ruderich wrote: > On Fri, Jun 30, 2017 at 09:04:50AM -0700, Stefan Beller wrote: >> [snip] >> >> However >> >> context >> + moved line, block A or B >> + moved line, block A or B >> context >> >> is omitted, because the number of lines >> here is

Re: [PATCH 25/25] diff: document the new --color-moved setting

On Fri, Jun 30, 2017 at 09:04:50AM -0700, Stefan Beller wrote: > [snip] > > However > > context > + moved line, block A or B > + moved line, block A or B > context > > is omitted, because the number of lines > here is fewer than 3 ignoring the block > type. > > Maybe > > If there are

Re: [GSoC][PATCH 5/5 v3] submodule: port submodule subcommand 'sync' from shell to C

On Fri, Jun 30, 2017 at 12:47 PM, Prathamesh Chavan wrote: > Port the submodule subcommand 'sync' from shell to C using the same > mechanism as that used for porting submodule subcommand 'status'. > Hence, here the function cmd_sync() is ported from shell to C. > This is done by introducing three

[GSoC][PATCH 1/5 v3] submodule--helper: introduce get_submodule_displaypath()

Introduce function get_submodule_displaypath() to replace the code occurring in submodule_init() for generating displaypath of the submodule with a call to it. This new function will also be used in other parts of the system in later patches. Mentored-by: Christian Couder Mentored-by: Stefan Bel

Re: [PATCHv3 2/3] patch-ids.c: use hashmap correctly

Stefan Beller writes: > As eluded to in the previous patch, the code in patch-ids.c is using > the hashmaps API wrong. > > Luckily we do not have a bug, as all hashmap functionality that we use > here (hashmap_get) passes through the keydata. If hashmap_get_next were > to be used, a bug would oc

[GSoC][PATCH 3/5 v3] submodule: port set_name_rev() from shell to C

Function set_name_rev() is ported from git-submodule to the submodule--helper builtin. The function get_name_rev() generates the value of the revision name as required, and the function print_name_rev() handles the formating and printing of the obtained revision name. Mentored-by: Christian Couder

[GSoC][PATCH 5/5 v3] submodule: port submodule subcommand 'sync' from shell to C

Port the submodule subcommand 'sync' from shell to C using the same mechanism as that used for porting submodule subcommand 'status'. Hence, here the function cmd_sync() is ported from shell to C. This is done by introducing three functions: module_sync(), sync_submodule() and print_default_remote(

[GSoC][PATCH 2/5 v3] submodule--helper: introduce for_each_submodule_list()

Introduce function for_each_submodule_list() and replace a loop in module_init() with a call to it. The new function will also be used in other parts of the system in later patches. Mentored-by: Christian Couder Mentored-by: Stefan Beller Signed-off-by: Prathamesh Chavan --- builtin/submodule

[GSoC][PATCH 4/5 v3] submodule: port submodule subcommand 'status' from shell to C

This aims to make git-submodule 'status' a built-in. Hence, the function cmd_status() is ported from shell to C. This is done by introducing three functions: module_status(), submodule_status() and print_status(). The function module_status() acts as the front-end of the subcommand. It parses subc

Re: Warning suggestion for git stash drop

Laurent Humblet writes: > Thank you for your feedback. > > I suppose that turning a hypothetical confirmation option 'on' would > impact a stash pop for instance as it automatically drops the stash if > it was applied without conflicts. > > What about a --confirm flag? You could then simply alia

[PATCHv3 3/3] hashmap: migrate documentation from Documentation/technical into header

While at it, clarify the use of `key`, `keydata`, `entry_or_key` as well as documenting the new data pointer for the compare function. Rework the example. Signed-off-by: Stefan Beller --- Documentation/technical/api-hashmap.txt | 309 hashmap.h

[PATCHv3 2/3] patch-ids.c: use hashmap correctly

As eluded to in the previous patch, the code in patch-ids.c is using the hashmaps API wrong. Luckily we do not have a bug, as all hashmap functionality that we use here (hashmap_get) passes through the keydata. If hashmap_get_next were to be used, a bug would occur as that passes NULL for the key

[PATCHv3 1/3] hashmap.h: compare function has access to a data field

When using the hashmap a common need is to have access to caller provided data in the compare function. A couple of times we abuse the keydata field to pass in the data needed. This happens for example in patch-ids.c. This patch changes the function signature of the compare function to have one mo

[PATCHv3 0/3] Introduce data field in hashmap and migrate docs to header

v3: * fixed first patch to call the data 'caller provided' instead of arbitrary. * moved the position of the caller provided data to first position * split up the rather mechanical change of function signature with fixing the API usage of patch-ids.c v2: addressed all but the last point of Jon

Re: [PATCHv2 1/2] hashmap.h: compare function has access to a data field

On Fri, Jun 30, 2017 at 11:47 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> Ok, let me redo the patch to have fndata at the front. >> >> Looking at other places (that have a similar mechanism mechanically, >> but are semantically different), such as the callback functions for >> the diff

Re: [PATCHv2 1/2] hashmap.h: compare function has access to a data field

Stefan Beller writes: > Ok, let me redo the patch to have fndata at the front. > > Looking at other places (that have a similar mechanism mechanically, > but are semantically different), such as the callback functions for > the diff machinery, we have the user provided pointer at the end > of the

Re: [PATCH 22/25] diff.c: color moved lines differently

Stefan Beller writes: > On Fri, Jun 30, 2017 at 10:54 AM, Junio C Hamano wrote: >> Stefan Beller writes: >> >>> +static int next_byte(const char **cp, const char **endp, >>> + const struct diff_options *diffopt) >>> +{ >>> + int retval; >>> + >>> + if (DIFF_XDL_TST(diff

Re: [PATCHv2 1/2] hashmap.h: compare function has access to a data field

Stefan Beller writes: > I am at a loss here after re-reading your answer over and over, > but I think you are asking if patch_id_cmp can break, as > we have a callchain like > > patch_id_cmp > commit_patch_id > (diff_root_tree_oid) > diff_tree_oid > ll_diff_tree_oid

MISE À NIVEAU EMAIL

-- Cher: Grenoble Institute of Technology Webmail, Nous vous annonons que votre compte de messagerie a dépassé son stockage limite. Vous ne pourrez pas envoyer et recevoir des mails et votre compte de messagerie Seront supprimés de notre serveur. Pour éviter ce problème, il est conseillé de

Re: Warning suggestion for git stash drop

Thank you for your feedback. I suppose that turning a hypothetical confirmation option 'on' would impact a stash pop for instance as it automatically drops the stash if it was applied without conflicts. What about a --confirm flag? You could then simply alias 'git stash drop --confirm' locally a

Re: RFC: Missing blob hook might be invoked infinitely recursively

On 6/29/2017 2:48 PM, Jonathan Tan wrote: As some of you may know, I'm currently working on support for partial clones/fetches in Git (where blobs above a user-specified size threshold are not downloaded - only their names and sizes are downloaded). To do this, the client repository needs to be

Re: [PATCH v8 6/6] convert: add "status=delayed" to filter process protocol

Lars Schneider writes: >> On 29 Jun 2017, at 20:34, Junio C Hamano wrote: >> >> You seem to have squashed an unrelated "table-driven" clean-up into >> this step. While I think the end result looks good, I would have >> liked to see it as a separate step, either as a preparatory "now we >> are

Re: [PATCH 22/25] diff.c: color moved lines differently

On Fri, Jun 30, 2017 at 10:54 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> +static int next_byte(const char **cp, const char **endp, >> + const struct diff_options *diffopt) >> +{ >> + int retval; >> + >> + if (DIFF_XDL_TST(diffopt, IGNORE_WHITESPACE_AT_EOL)) {

Re: [PATCHv2 1/2] hashmap.h: compare function has access to a data field

On Fri, Jun 30, 2017 at 10:39 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> diff --git a/patch-ids.c b/patch-ids.c >> index 9c0ab9e67a..b9b2ebbad0 100644 >> --- a/patch-ids.c >> +++ b/patch-ids.c >> @@ -37,6 +37,7 @@ int commit_patch_id(struct commit *commit, struct >> diff_options *opt

Re: [PATCH] merge-recursive: use DIFF_XDL_SET macro

Stefan Beller writes: > Instead of implementing this on our own, just use a convenience macro. > > Signed-off-by: Stefan Beller > --- Good eyes. Thanks. > merge-recursive.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/merge-recursive.c b/merge-recursive.c >

Re: [PATCH 22/25] diff.c: color moved lines differently

Stefan Beller writes: > +static int next_byte(const char **cp, const char **endp, > + const struct diff_options *diffopt) > +{ > + int retval; > + > + if (DIFF_XDL_TST(diffopt, IGNORE_WHITESPACE_AT_EOL)) { > + while (*endp > *cp && isspace(**endp)) > +

Re: [PATCHv2 1/2] hashmap.h: compare function has access to a data field

On Fri, Jun 30, 2017 at 10:34 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> When using the hashmap a common need is to have access to arbitrary data >> in the compare function. A couple of times we abuse the keydata field >> to pass in the data needed. This happens for example in patch-i

Re: [PATCHv2 1/2] hashmap.h: compare function has access to a data field

Stefan Beller writes: > diff --git a/patch-ids.c b/patch-ids.c > index 9c0ab9e67a..b9b2ebbad0 100644 > --- a/patch-ids.c > +++ b/patch-ids.c > @@ -37,6 +37,7 @@ int commit_patch_id(struct commit *commit, struct > diff_options *options, > */ > static int patch_id_cmp(struct patch_id *a, >

Re: [PATCHv2 1/2] hashmap.h: compare function has access to a data field

Stefan Beller writes: > When using the hashmap a common need is to have access to arbitrary data > in the compare function. A couple of times we abuse the keydata field > to pass in the data needed. This happens for example in patch-ids.c. It is not "arbitrary data"; it is very important to stre

Re: git log use of date format differs between Command Line and script usage.

Yes. That is the case. Just confirmed it. I'll remove the old version. Sorry to have bothered the mailing list. Thank you. -Shaun On Fri, Jun 30, 2017 at 12:43 PM, Stefan Beller wrote: > On Fri, Jun 30, 2017 at 9:06 AM, Shaun Uldrikis wrote: >> If you supply a non-standard format to the date c

Re: [PATCH 1/2] hashmap.h: compare function has access to a data field

Stefan Beller writes: > Yes it was a last minute squash before sending it out, as the fix was only > two lines whereas the conversion is a lot. If it were separated I could have > claimed the introduction to be a rather mechanical patch, but I did not > make use of coccinelle or such, so the like

Re: [PATCH v2 5/6] grep: remove regflags from the public grep_opt API

Ævar Arnfjörð Bjarmason writes: > @@ -169,6 +167,24 @@ void grep_init(struct grep_opt *opt, const char *prefix) > > static void grep_set_pattern_type_option(enum grep_pattern_type > pattern_type, struct grep_opt *opt) > { > + /* > + * When committing to the pattern type by setting

Re: [PATCH] hooks: add signature to the top of the commit message

Kaartic Sivaraam writes: > The sample hook to prepare the commit message before > a commit allows users to opt-in to add the signature > to the commit message. The signature is added at a place > that isn't consistent with the "-s" option of "git commit". > Further, it could go out of view in cer

Re: git log use of date format differs between Command Line and script usage.

On Fri, Jun 30, 2017 at 9:06 AM, Shaun Uldrikis wrote: > If you supply a non-standard format to the date configuration for git > log, something like: > [log] > date = format:%Y-%m-%d %H:%M So I ran $ git config log.date "format:%Y-%m-%d %H:%M" $ git config --list |grep log.date

Re: git log use of date format differs between Command Line and script usage.

Am 30.06.2017 um 18:06 schrieb Shaun Uldrikis: If you supply a non-standard format to the date configuration for git log, something like: [log] date = format:%Y-%m-%d %H:%M then, when you run 'git log' inside a script, or when using gitk (anywhere), it fails on decoding the format. fat

[PATCH] status: suppress additional warning output in plumbing modes

When status is called with '--porcelain' (as implied by '-z'), we promise to output only messages as described in the man page. Suppress CRLF warnings. Signed-off-by: Stefan Beller --- Maybe something like this? builtin/commit.c | 5 + 1 file changed, 5 insertions(+) diff --git a/builtin

git log use of date format differs between Command Line and script usage.

If you supply a non-standard format to the date configuration for git log, something like: [log] date = format:%Y-%m-%d %H:%M then, when you run 'git log' inside a script, or when using gitk (anywhere), it fails on decoding the format. fatal: unknown date format format: %Y-%m-%d %H:%M H

Re: [PATCH 25/25] diff: document the new --color-moved setting

On Fri, Jun 30, 2017 at 12:26 AM, Simon Ruderich wrote: > On Thu, Jun 29, 2017 at 05:07:10PM -0700, Stefan Beller wrote: >> + Small blocks of 3 moved lines or fewer are skipped. > > If I read the commit messages correctly, this "skipping" process > applies to the move detection in general for

Re: [PATCH] git-p4: parse marshal output "p4 -G" in p4 changes

On Fri, Jun 30, 2017 at 12:13 PM, Lars Schneider wrote: > >> On 30 Jun 2017, at 11:41, Miguel Torroja wrote: >> >> On Fri, Jun 30, 2017 at 10:26 AM, Lars Schneider >> wrote: >>> On 30 Jun 2017, at 00:46, miguel torroja wrote: The option -G of p4 (python marshal output) gives more

[PATCH] hooks: add signature to the top of the commit message

The sample hook to prepare the commit message before a commit allows users to opt-in to add the signature to the commit message. The signature is added at a place that isn't consistent with the "-s" option of "git commit". Further, it could go out of view in certain cases. Add the signature to the

  1   2   >