[PATCH 2/2] 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. Signed-off-by: Stefan Beller --- Documentation/technical/api-hashmap.txt | 309 hashmap.h

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

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. This patch changes the function signature of the compare function to have one more

[PATCH 0/2] Introduce data field in hashmap and migrate docs to header

https://public-inbox.org/git/xmqqpodnvmmw@gitster.mtv.corp.google.com/ for context why we need a new data field. Implement that. Once upon a time we had a long discussion where to put documentation best. The answer was header files as there documentation has less chance to become stale and

Re: [PATCH v4 4/6] coccinelle: add a rule to make "expression" code use FREE_AND_NULL()

Ævar Arnfjörð Bjarmason writes: > I get exactly the same thing as you do below when following these > steps. So it seems your patch in > 2122b01f-7627-cd1b-c7df-751c076f9...@web.de is just fine as-is and I > just screwed something up when testing this. > > Sorry about the

Re: [PATCH v4 4/6] coccinelle: add a rule to make "expression" code use FREE_AND_NULL()

Am 29.06.2017 um 00:21 schrieb René Scharfe: $ git am # pasted my email Applying: coccinelle: add a rule to make "expression" code use FREE_AND_NULL() # results in commit message with scissor line, interesting.. "git am --scissors" commits with the correct message. I'll do a "git config

Re: [PATCH v4 4/6] coccinelle: add a rule to make "expression" code use FREE_AND_NULL()

On Thu, Jun 29, 2017 at 12:30 AM, René Scharfe wrote: > Am 29.06.2017 um 00:21 schrieb René Scharfe: >> >> Am 28.06.2017 um 23:39 schrieb Ævar Arnfjörð Bjarmason: >>> >>> >>> On Sun, Jun 25 2017, René Scharfe jotted: >>> Am 16.06.2017 um 21:43 schrieb Junio C Hamano: >

Re: [PATCH v4 4/6] coccinelle: add a rule to make "expression" code use FREE_AND_NULL()

Am 29.06.2017 um 00:21 schrieb René Scharfe: Am 28.06.2017 um 23:39 schrieb Ævar Arnfjörð Bjarmason: On Sun, Jun 25 2017, René Scharfe jotted: Am 16.06.2017 um 21:43 schrieb Junio C Hamano: Ævar Arnfjörð Bjarmason writes: A follow-up to the existing "type" rule added

Re: [PATCH v4 4/6] coccinelle: add a rule to make "expression" code use FREE_AND_NULL()

On Wed, Jun 28 2017, René Scharfe jotted: > Am 28.06.2017 um 23:39 schrieb Ævar Arnfjörð Bjarmason: >> >> On Sun, Jun 25 2017, René Scharfe jotted: >> >>> Am 16.06.2017 um 21:43 schrieb Junio C Hamano: Ævar Arnfjörð Bjarmason writes: > A follow-up to the

IP/ID Offer

Dear Sir/Ma I am brokering an Investment deal in your country on behalf of a client. This deal will involve the eventual investment of US$50M ( Fifty Million United States Dollars) within your country. I want to offer you an opportunity to be part of this profitable and life time business

Re: [PATCH v4 4/6] coccinelle: add a rule to make "expression" code use FREE_AND_NULL()

Am 28.06.2017 um 23:39 schrieb Ævar Arnfjörð Bjarmason: > > On Sun, Jun 25 2017, René Scharfe jotted: > >> Am 16.06.2017 um 21:43 schrieb Junio C Hamano: >>> Ævar Arnfjörð Bjarmason writes: >>> A follow-up to the existing "type" rule added in an earlier change. This

Re: [PATCH v4 4/6] coccinelle: add a rule to make "expression" code use FREE_AND_NULL()

On Wed, Jun 28 2017, Junio C. Hamano jotted: > Ævar Arnfjörð Bjarmason writes: > >> Late reply, sorry. What version of coccinelle are you running? I have >> 1.0.4 (from Debian) and can't get this to produce the same results as >> what I have. >> >> On top of next, I did: >> >>

What's cooking in git.git (Jun 2017, #08; Wed, 28)

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

Re: [PATCH v2 0/3] update sha1dc from PR #36

Ævar Arnfjörð Bjarmason writes: > On Tue, Jun 27 2017, Junio C. Hamano jotted: > >> Ævar Arnfjörð Bjarmason writes: >> >>> A v2 addressing comments to the v1, tbdiff below. Just fixes the >>> subject line on 1/3 & gets rid of the redundant _BIG_ENDIAN

Re: [PATCH v4 4/6] coccinelle: add a rule to make "expression" code use FREE_AND_NULL()

Ævar Arnfjörð Bjarmason writes: > Late reply, sorry. What version of coccinelle are you running? I have > 1.0.4 (from Debian) and can't get this to produce the same results as > what I have. > > On top of next, I did: > > Revert "*.[ch] refactoring: make use of the

[PATCH 1/5] grep: remove redundant double assignment to 0

Stop assigning 0 to the extended_regexp_option field right after we've zeroed out the entire struct with memset() just a few lines earlier. Unlike some of the code being refactored in subsequent commits, this was always completely redundant. See the original code introduced in 84befcd0a4 ("grep:

[PATCH 4/5] grep: remove redundant and verbose re-assignments to 0

Remove the redundant re-assignments of the fixed/pcre1/pcre2 fields to zero right after the entire struct has been set to zero via memset(...). See an earlier related cleanup commit e0b9f8ae09 ("grep: remove redundant regflags assignments", 2017-05-25) for an explanation of why the code was

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

Refactor calls to the grep machinery to always pass opt.ignore_case & opt.extended_regexp_option instead of setting the equivalent regflags bits. The bug fixed when making -i work with -P in commit 9e3cbc59d5 ("log: make --regexp-ignore-case work with --perl-regexp", 2017-05-20) was really just

[PATCH 3/5] grep: remove redundant "fixed" field re-assignment to 0

Remove the redundant re-assignment of the fixed field to zero right after the entire struct has been set to zero via memset(...). Unlike some nearby commits this pattern doesn't date back to the pattern described in e0b9f8ae09 ("grep: remove redundant regflags assignments", 2017-05-25), instead

[PATCH 2/5] grep: remove redundant grep pattern type assignment

Remove a redundant assignment to extended_regexp_option to make it zero if grep.extendedRegexp is not set. This is always called right after init_grep_defaults() which memsets the entire structure to 0. This is a logical follow-up to my commit to remove redundant regflags assignments[1]. This

[PATCH 0/5] grep: remove redundant code & reflags from API

Here's a follow-up to a small tangent of discussion in my ~30 patch grep cleanup series. There are no functional changes here, just getting rid of dead code, and removing the POSIX `regflags` variable from the grep API used by grep/log, which was the cause of the long-standing bug of "-i" not

Re: [PATCH v2 0/3] update sha1dc from PR #36

On Tue, Jun 27 2017, Junio C. Hamano jotted: > Ævar Arnfjörð Bjarmason writes: > >> A v2 addressing comments to the v1, tbdiff below. Just fixes the >> subject line on 1/3 & gets rid of the redundant _BIG_ENDIAN detection >> for Solaris, we can just use __sparc (and indeed we

Re: [PATCH v4 4/6] coccinelle: add a rule to make "expression" code use FREE_AND_NULL()

On Sun, Jun 25 2017, René Scharfe jotted: > Am 16.06.2017 um 21:43 schrieb Junio C Hamano: >> Ævar Arnfjörð Bjarmason writes: >> >>> A follow-up to the existing "type" rule added in an earlier >>> change. This catches some occurrences that are missed by the previous >>> rule.

[PATCH v8 5/6] 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

[PATCH v8 6/6] 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 v8 3/6] 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

[PATCH v8 2/6] 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"

[PATCH v8 4/6] 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

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

Hi, here is the 8th iteration of my "status delayed" topic. Patch 1 to 3 are minor t0021 test adjustments. Patch 4 is a minor convert.c style adjustment. Patch 5 is a minor "extract method" refactoring in convert.c with an additional minor style adjustment. Patch 6 is the new feature. ###

[PATCH v8 1/6] 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

Re: [PATCH] submodule--helper: do not call utf8_fprintf() unnecessarily

On Wed, Jun 28, 2017 at 1:58 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> On Wed, Jun 28, 2017 at 1:38 PM, Junio C Hamano wrote: >>> The helper function utf8_fprintf(fp, ...) has exactly the same >>> effect to the output stream

Re: [PATCH 6/6] diff.c: detect blocks despite whitespace changes

Stefan Beller writes: > Originally I wanted to do that, see prep work in [1], but Jeff explained that > the additional pointer in the compare function is **not** supposed to be > a additional payload (such as the diff options specifying the white space > options.) > > [1]

Re: [PATCH] submodule--helper: do not call utf8_fprintf() unnecessarily

Stefan Beller writes: > On Wed, Jun 28, 2017 at 1:38 PM, Junio C Hamano wrote: >> The helper function utf8_fprintf(fp, ...) has exactly the same >> effect to the output stream fp as fprintf(fp, ...) does, and the >> only difference is that its return value

Re: [PATCH] submodule--helper: do not call utf8_fprintf() unnecessarily

On Wed, Jun 28, 2017 at 1:38 PM, Junio C Hamano wrote: > The helper function utf8_fprintf(fp, ...) has exactly the same > effect to the output stream fp as fprintf(fp, ...) does, and the > only difference is that its return value counts in display columns > consumed (assuming

[PATCH] submodule--helper: do not call utf8_fprintf() unnecessarily

The helper function utf8_fprintf(fp, ...) has exactly the same effect to the output stream fp as fprintf(fp, ...) does, and the only difference is that its return value counts in display columns consumed (assuming that the payload is encoded in UTF-8), as opposed to number of bytes. There is no

Re: [PATCH 6/6] diff.c: detect blocks despite whitespace changes

On Tue, Jun 27, 2017 at 10:06 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Looking at the implementation of get_ws_cleaned_string() that is the >> workhorse of emitted_symbol_cmp_no_ws(), it seems to be doing wrong >> things for various "ignore

Re: [PATCH 5/6] diff.c: omit uninteresting moved lines

On Tue, Jun 27, 2017 at 8:31 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> It is useful to have moved lines colored, but there are annoying corner >> cases, such as a single line moved, that is very common. For example >> in a typical patch of C

Re: [PATCH 2/6] diff.c: change the default for move coloring to zebra

On Tue, Jun 27, 2017 at 8:14 PM, Junio C Hamano wrote: >> diff --git a/diff.h b/diff.h >> index 98abd75521..9298d211d7 100644 >> --- a/diff.h >> +++ b/diff.h >> @@ -192,6 +192,7 @@ struct diff_options { >> COLOR_MOVED_NO = 0, >> COLOR_MOVED_PLAIN =

Re: [GSoC][PATCH 1/6 v2] submodule--helper: introduce for_each_submodule_list

Prathamesh Chavan writes: > Introduce function for_each_submodule_list for using it > in the later patches, related to porting submodule > subcommands from shell to C. > This new function is also used in ported submodule subcommand > init. The patch text looks sensible. It

Re: [PATCH 1/3] list-objects: add filter_blob to traverse_commit_list

Jeff Hostetler writes: > Yes, my logic was a little confusing there. Jonathan Tan said > something similar the other day. I have a new version that I'm > working on now that looks like this: > > list_objects_filter_result r = LOFR_MARK_SEEN | LOFR_SHOW; >

Re: [PATCH/RFC v1 1/1] cygwin: Allow pushing to UNC paths

tbo...@web.de writes: > From: Torsten Bögershausen > > cygwin can use an UNC path like //server/share/repo > $ cd //server/share/dir > $ mkdir test > $ cd test > $ git init --bare > > However, when we try to push from a local Git repository to this repo, > there are 2 problems: >

[PATCH] t1450: use egrep for regexp "alternation"

GNU grep allows "\(A\|B\)" as alternation in BRE, but this is an extension not understood by some other implementations of grep (Michael Kebe reported an breakage on Solaris). Rewrite the offending test to ERE and use egrep instead. Noticed-by: Michael Kebe

Re: Solaris 11.3 SPARC grep problem with t1450-fsck.sh

Michael Kebe writes: > 2017-06-27 18:25 GMT+02:00 Junio C Hamano : >> Ah, wait, that particular grep may have GNUism. If you changed it >> to >> >> egrep "$tree \((refs/heads/master|HEAD)@{[0-9]*}:" out >> >> does it make it pass for you? > > Yes,

Re: [PATCH 1/3] list-objects: add filter_blob to traverse_commit_list

On 6/28/2017 12:23 PM, Junio C Hamano wrote: Jeff Hostetler writes: diff --git a/list-objects.c b/list-objects.c index f3ca6aa..c9ca81c 100644 --- a/list-objects.c +++ b/list-objects.c @@ -24,11 +25,28 @@ static void process_blob(struct rev_info *revs,

Re: [PATCH] commit-template: improve readability of commit template

Kaartic Sivaraam writes: > The commit template adds the optional parts without > a new line to distinguish them. This results in > difficulty in interpreting it's content. Add new > lines to separate the distinct parts of the template. > > The warning about usage

[PATCH/RFC v1 1/1] cygwin: Allow pushing to UNC paths

From: Torsten Bögershausen cygwin can use an UNC path like //server/share/repo $ cd //server/share/dir $ mkdir test $ cd test $ git init --bare However, when we try to push from a local Git repository to this repo, there are 2 problems: - Git converts the leading "//" into a

Re: [PATCH 1/3] list-objects: add filter_blob to traverse_commit_list

Jeff Hostetler writes: > diff --git a/list-objects.c b/list-objects.c > index f3ca6aa..c9ca81c 100644 > --- a/list-objects.c > +++ b/list-objects.c > @@ -24,11 +25,28 @@ static void process_blob(struct rev_info *revs, > die("bad blob object"); > if

Re: [PATCH/RFC] commit-template: improve readability of commit template

I might have been ignorant about something about git in my reply in the previous email (found below). In that case, please enlighten me. On Wed, 2017-06-28 at 18:34 +0530, Kaartic Sivaraam wrote: > On Tue, 2017-06-27 at 10:56 -0700, Junio C Hamano wrote: > > Kaartic Sivaraam

Re: [PATCH] commit-template: improve readability of commit template

I forgot to add the RFC in the subject in a hurry. Please consider it's presence. -- Regards, Kaartic Sivaraam

Re: Bug: Cannot kill Nodejs process using ctrl + c

Hi, On Mon, 26 Jun 2017, Gyandeep Singh wrote: > 3. hit "CTRL + c" (2 times) to kill the process. > 4. If you look at taskmanager, then you will see a node.js process > still running. or if you try to restart the server it will say port > 300 already in use. The way Ctrl+C is handled in Git for

[PATCH] commit-template: improve readability of commit template

The commit template adds the optional parts without a new line to distinguish them. This results in difficulty in interpreting it's content. Add new lines to separate the distinct parts of the template. The warning about usage of 'explicit paths without any corresponding options' has outlived

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

Thanks Luke, regarding the error in t9800 (not ok 18 - unresolvable host in P4PORT should display error), for me it's very weird too as it doesn't seem to be related to this particular change, as the patch changes are not exercised with that test. The test 21 in t9807 was precisely the new test

Re: [PATCH/RFC] commit-template: improve readability of commit template

On Tue, 2017-06-27 at 10:56 -0700, Junio C Hamano wrote: > Kaartic Sivaraam writes: > > I thought it's not good to trade-off readability for vertical space > > as > > the ultimate aim of the commit template (at least to me) is to > > convey > > information to the

Re: Bug: submodules of submodules use absolute gitdir in .git file (instead of relative)

I had the problem with version 2.7.4. The problem is fixed in self-compiled v2.13.2.533.ge0aaa1bed, v2.12.0, v2.11.0 and v2.9.3! Even the older version 2.1.4 does not have that problem. Thank you for the input! Robert From: Siemer Robert CSNPE Sent:

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

On 28 June 2017 at 05:08, Junio C Hamano wrote: > Miguel Torroja writes: > >> The option -G of p4 (python marshal output) gives more context about the >> data being output. That's useful when using the command "change -o" as >> we can distinguish

Re: [PATCH 1/1] ls-remote: remove "-h" from help text

Hi Jonathan, > > This regression was fixed in 91a640ffb6d9 ("ls-remote: a lone "-h" is > > [...] > > Without this patch, I'm able to run > > git ls-remote -h . > > This patch removes that support. Intended? *hihi* okay it was to counter-intuitive for me. "91a640ffb6d" talks about this

enquiry 28-06-17

Hello, My name is Ms Julian Smith and i am from Sinara Group Co.Ltd in Russia..We are glad to know about your company from the web and we are interested in your products.Please send us your Latest catalog and price list for our trial order Julian Smith, Purchasing Manager

Re: Bug: Since Git 2.13.2 git rebase autostash doesn't use fast-forward (poor performance)

Could you see this as suggestion for performance improvement or should I send another e-mail for a new task? Regards, Mattias Junio C Hamano schrieb am 27.06.2017 17:02:14: > Von: Junio C Hamano > An: neul...@dakosy.de > Kopie: git@vger.kernel.org >

Re: Solaris 11.3 SPARC grep problem with t1450-fsck.sh

2017-06-27 18:25 GMT+02:00 Junio C Hamano : > Ah, wait, that particular grep may have GNUism. If you changed it > to > > egrep "$tree \((refs/heads/master|HEAD)@{[0-9]*}:" out > > does it make it pass for you? Yes, this is working. Greetings Michael