Re: [PATCH] Feature: custom guitool commands can now have custom keyboard shortcuts

Hi Pratyush, On Sun, 6 Oct 2019, Pratyush Yadav wrote: > On 06/10/19 01:46AM, Harish Karumuthil wrote: > > > > From https://www.kernel.org/doc/html/v4.10/process/email-clients.html, I > > understood that, my current email client ( that is gmail web ) is not good > > for submitting patches. So I w

Re: [PATCH v2 1/1] fetch: let --jobs= parallelize --multiple, too

Hi Junio, On Sun, 6 Oct 2019, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" > writes: > > > +test_expect_success 'parallel' ' > > + git remote add one ./bogus1 && > > + git remote add two ./bogus2 && > > + > > + test_must_fail env GIT_TRACE="$PWD/trace" \ > > + g

Re: PATCH] remove duplicate #include directives

Am 06.10.19 um 01:41 schrieb Junio C Hamano: > René Scharfe writes: >> This one here requires one more piece of information, though, namely our >> convention of wrapping header files in guard defines to make repeated >> includes of them no-ops. We do that for those removed by the patch, but >> we

Re: [PATCH v3 00/13] ci: include a Visual Studio build & test in our Azure Pipeline

Hi Junio, On Sun, 6 Oct 2019, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" > writes: > > > Range-diff vs v2: > > > > 1: 4d0b38125a = 1: 4d0b38125a push: do not pretend to return `int` > > from `die_push_simple()` > > 2: 8800320590 < -: -- msvc: avoid using mi

Re: [PATCH v2 02/13] msvc: avoid using minus operator on unsigned types

Am 06.10.19 um 02:02 schrieb Junio C Hamano: > Johannes Schindelin writes: > >>> IMHO, if you don't accompany insert_pos_as_negative_offset() with a >>> corresponding extract_pos_and_found_condition() and use it everywhere, >>> it is more obfuscating than necessary. >> >> I do disagree here. No o

[PATCH] tests: remove "cat foo" before "test_i18ngrep bar foo"

Some tests print a file before searching for a pattern using test_i18ngrep. This is useful when debugging tests with --verbose when the pattern is not found as expected. Since 63b1a175ee (t: make 'test_i18ngrep' more informative on failure, 2018-02-08) test_i18ngrep already shows the contents of

Re: [PATCH v4 1/6] rebase -i: add --ignore-whitespace flag

Hi Phillip On Fri, 4 Oct 2019 10:29:36 +0100 Phillip Wood wrote: > > [...] > --rebase-merges now supports --strategy_option so we should fix this. Yes, now that it supports --strategy_options I'll remove it from here. > [...] Thanks Rohit

Re: [PATCH v4 3/6] rebase -i: support --committer-date-is-author-date

On Fri, 4 Oct 2019 10:37:43 +0100 Phillip Wood wrote: > > > + if (opts->committer_date_is_author_date) { > > + int len = strlen(author); > > + struct ident_split ident; > > + struct strbuf date = STRBUF_INIT; > > + > > + if (split_ident_line(&ident, autho

Re: [PATCH v4 5/6] rebase -i: support --ignore-date

On Fri, 27 Sep 2019 11:00:58 +0100 Phillip Wood wrote: > > [...] Thanks for all the advice and improvements. > [...] > It's good to see the new test. Did you see Stolee's email [4] about the > test coverage of the previous version of this series? You should check > that this series tests all th

Re: [PATCH] Feature: custom guitool commands can now have custom keyboard shortcuts

On 06/10/19 11:49AM, Johannes Schindelin wrote: > Hi Pratyush, > > On Sun, 6 Oct 2019, Pratyush Yadav wrote: > > > On 06/10/19 01:46AM, Harish Karumuthil wrote: > > > > > > From https://www.kernel.org/doc/html/v4.10/process/email-clients.html, I > > > understood that, my current email client ( th

Re: [PATCH] Feature: custom guitool commands can now have custom keyboard shortcuts

On 06/10/2019 19:39, Pratyush Yadav wrote: That way, you don't have to introduce settings separate from `git-cola`'s, and you can reuse the short-and-sweet variable name. I think a more important question is whether we_really_ need to have compatibility with git-cola. Most of our shortcuts don'

Re: [PATCH] Feature: custom guitool commands can now have custom keyboard shortcuts

Hi Pratyush, On Mon, 7 Oct 2019, Pratyush Yadav wrote: > On 06/10/19 11:49AM, Johannes Schindelin wrote: > > Hi Pratyush, > > > > On Sun, 6 Oct 2019, Pratyush Yadav wrote: > > > > > On 06/10/19 01:46AM, Harish Karumuthil wrote: > > > > > > > > From https://www.kernel.org/doc/html/v4.10/process/em

Re: [PATCH v3 00/13] ci: include a Visual Studio build & test in our Azure Pipeline

Hi Junio, On Sun, 6 Oct 2019, Johannes Schindelin wrote: > On Sun, 6 Oct 2019, Junio C Hamano wrote: > > > "Johannes Schindelin via GitGitGadget" > > writes: > > > > > Range-diff vs v2: > > > > > > 1: 4d0b38125a = 1: 4d0b38125a push: do not pretend to return `int` > > > from `die_push_simp

Re: [PATCH] Feature: custom guitool commands can now have custom keyboard shortcuts

On 06/10/19 10:27PM, Johannes Schindelin wrote: > Hi Pratyush, > > On Mon, 7 Oct 2019, Pratyush Yadav wrote: > > > On 06/10/19 11:49AM, Johannes Schindelin wrote: > > > Hi Pratyush, > > > > > > On Sun, 6 Oct 2019, Pratyush Yadav wrote: > > > > > > > On 06/10/19 01:46AM, Harish Karumuthil wrote: >

[PATCH v2] git-gui: add a readme

It is a good idea to have a readme so people finding the project can know more about it, and know how they can get involved. Signed-off-by: Pratyush Yadav --- Changes in v2: - s/Gui/GUI/g suggested by Johannes. - s/git/Git/ wherever applicable suggested by Johannes. - Clarify that there is

Re: [PATCH] Feature: custom guitool commands can now have custom keyboard shortcuts

Hi Dscho, On 06/10/2019 21:27, Johannes Schindelin wrote: Let me provide you with some data, then. Granted, it's not necessarily all Git GUI, but it includes Git GUI patches, too: Git for Windows' contributions. As should be well-known, I try to follow Postel's Law when it comes to Git for Wind

[PATCH v3 00/20] hashmap bug/safety/ease-of-use fixes

v3 changes: - use __typeof__ to avoid invalid clang warning on uninitialized var - formatting fixes recommended by Stolee - add Reviewed-by for Stolee - add patch 20 to update docs to drop first member requirement v2 here: https://public-inbox.org/git/20190924010324.22619-...@80x24.org/ The fol

[PATCH v3 03/20] packfile: use hashmap_entry in delta_base_cache_entry

This hashmap_entry_init function is intended to take a hashmap_entry struct pointer, not a hashmap struct pointer. This was not noticed because hashmap_entry_init takes a "void *" arg instead of "struct hashmap_entry *", and the hashmap struct is larger and can be cast into a hashmap_entry struct

[PATCH v3 02/20] coccicheck: detect hashmap_entry.hash assignment

Assigning hashmap_entry.hash manually leaves hashmap_entry.next uninitialized, which can be dangerous once the hashmap_entry is inserted into a hashmap. Detect those assignments and use hashmap_entry_init, instead. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- contrib/coccinelle/ha

[PATCH v3 01/20] diff: use hashmap_entry_init on moved_entry.ent

Otherwise, the hashmap_entry.next field appears to remain uninitialized, which can lead to problems when add_lines_to_move_detection calls hashmap_add. I found this through manual inspection when converting hashmap_add callers to take "struct hashmap_entry *". Signed-off-by: Eric Wong Reviewed-b

[PATCH v3 04/20] hashmap_entry_init takes "struct hashmap_entry *"

C compilers do type checking to make life easier for us. So rely on that and update all hashmap_entry_init callers to take "struct hashmap_entry *" to avoid future bugs while improving safety and readability. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- attr.c | 4

[PATCH v3 07/20] hashmap_get takes "const struct hashmap_entry *"

This is less error-prone than "const void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- attr.c| 2 +- blame.c | 6 +++--- builtin/difftool.c| 5 +++-- builtin/fast-export.c | 2 +- config.c

[PATCH v3 10/20] introduce container_of macro

This macro is popular within the Linux kernel for supporting intrusive data structures such as linked lists, red-black trees, and chained hash tables while allowing the compiler to do type checking. Later patches will use container_of() to remove the limitation of "hashmap_entry" being location-de

[PATCH v3 09/20] hashmap_put takes "struct hashmap_entry *"

This is less error-prone than "void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- builtin/fast-export.c | 2 +- hashmap.c | 2 +- hashmap.h | 2 +- merge-recursive.c | 4 ++-- oidmap.c

[PATCH v3 06/20] hashmap_add takes "struct hashmap_entry *"

This is less error-prone than "void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- attr.c | 2 +- blame.c | 2 +- builtin/describe.c | 2 +- builtin/difftool.c | 6 +++--- builtin/fet

[PATCH v3 08/20] hashmap_remove takes "const struct hashmap_entry *"

This is less error-prone than "const void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- blame.c| 2 +- hashmap.c | 3 ++- hashmap.h | 2 +- merge-recursive.c | 2 +- name-hash.c| 4 ++--

[PATCH v3 15/20] hashmap: use *_entry APIs for iteration

Inspired by list_for_each_entry in the Linux kernel. Once again, these are somewhat compromised usability-wise by compilers lacking __typeof__ support. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- attr.c | 5 +++-- blame.c |

[PATCH v3 05/20] hashmap_get_next takes "const struct hashmap_entry *"

This is less error-prone than "const void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- diff.c | 5 +++-- diffcore-rename.c | 2 +- hashmap.c | 5 +++-- hashmap.h | 3 ++- na

[PATCH v3 13/20] hashmap_get{,_from_hash} return "struct hashmap_entry *"

Update callers to use hashmap_get_entry, hashmap_get_entry_from_hash or container_of as appropriate. This is another step towards eliminating the requirement of hashmap_entry being the first field in a struct. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- attr.c| 2

[PATCH v3 16/20] hashmap: hashmap_{put,remove} return hashmap_entry *

And add *_entry variants to perform container_of as necessary to simplify most callers. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- hashmap.c | 8 +--- hashmap.h | 15 --- range-diff.c| 4 +++- remote.c| 3 +

[PATCH v3 11/20] hashmap_get_next returns "struct hashmap_entry *"

This is a step towards removing the requirement for hashmap_entry being the first field of a struct. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- diff.c | 19 --- diffcore-rename.c | 11 +++ hashmap.c | 2 +- hashmap.h

[PATCH v3 12/20] hashmap: use *_entry APIs to wrap container_of

Using `container_of' can be verbose and choosing names for intermediate "struct hashmap_entry" pointers is a hard problem. So introduce "*_entry" APIs inspired by similar linked-list APIs in the Linux kernel. Unfortunately, `__typeof__' is not portable C, so we need an extra parameter to specify t

[PATCH v3 14/20] hashmap_cmp_fn takes hashmap_entry params

Another step in eliminating the requirement of hashmap_entry being the first member of a struct. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee --- attr.c | 10 ++ builtin/describe.c | 10 ++ builtin/difftool.c | 31 +++---

[PATCH v3 18/20] OFFSETOF_VAR macro to simplify hashmap iterators

While we cannot rely on a `__typeof__' operator being portable to use with `offsetof'; we can calculate the pointer offset using an existing pointer and the address of a member using pointer arithmetic for compilers without `__typeof__'. This allows us to simplify usage of hashmap iterator macros

[PATCH v3 17/20] hashmap: introduce hashmap_free_entries

`hashmap_free_entries' behaves like `container_of' and passes the offset of the hashmap_entry struct to the internal `hashmap_free_' function, allowing the function to free any struct pointer regardless of where the hashmap_entry field is located. `hashmap_free' no longer takes any arguments aside

[PATCH v3 20/20] hashmap_entry: remove first member requirement from docs

Comments stating that "struct hashmap_entry" must be the first member in a struct are no longer valid. Suggested-by: Phillip Wood Signed-off-by: Eric Wong --- attr.c | 2 +- builtin/fetch.c | 2 +- hashmap.h | 4 ++-- merge-recursive.h | 4 ++-- ref-

[PATCH v3 19/20] hashmap: remove type arg from hashmap_{get,put,remove}_entry

Since these macros already take a `keyvar' pointer of a known type, we can rely on OFFSETOF_VAR to get the correct offset without relying on non-portable `__typeof__' and `offsetof'. Argument order is also rearranged, so `keyvar' and `member' are sequential as they are used as: `keyvar->member' S

Re: [PATCH v3 00/13] ci: include a Visual Studio build & test in our Azure Pipeline

Johannes Schindelin writes: > Date: Fri, 04 Oct 2019 08:09:25 -0700 (PDT) > [...] > X-Google-Original-Date: Fri, 04 Oct 2019 15:09:10 GMT > [...] > > I am fairly certain that the latter is the actual `Date:` line sent to > GMail, and GMail just decides that it will not r

Re: [PATCH v3 00/13] ci: include a Visual Studio build & test in our Azure Pipeline

Johannes Schindelin writes: >> I just implemented this here: >> https://github.com/gitgitgadget/gitgitgadget/pull/128 (it still needs to >> be reviewed and merged before it takes effect). > > FWIW this is now merged. Nice. I didn't quite understand this part, though. The default creation f

Re: [PATCH v2 1/1] fetch: let --jobs= parallelize --multiple, too

Johannes Schindelin writes: > Hi Junio, > ... >> Thanks. I think it is much better to prepare these tests like this >> patch does to be broken when phrasing changes---that would give >> feedback and confidence to the person who is changing the message >> and/or the logic to emit the message. >>

Re: [PATCH] tests: remove "cat foo" before "test_i18ngrep bar foo"

René Scharfe writes: > Some tests print a file before searching for a pattern using > test_i18ngrep. This is useful when debugging tests with --verbose when > the pattern is not found as expected. > > Since 63b1a175ee (t: make 'test_i18ngrep' more informative on failure, > 2018-02-08) test_i18ng

Re: [PATCH v3 00/20] hashmap bug/safety/ease-of-use fixes

Eric Wong writes: > v3 changes: > - use __typeof__ to avoid invalid clang warning on uninitialized var > - formatting fixes recommended by Stolee > - add Reviewed-by for Stolee > - add patch 20 to update docs to drop first member requirement I just did git checkout ew/hashmap gi

Re: [PATCH v2] git-gui: add a readme

Pratyush Yadav writes: > -+# Git Gui - A graphical user interface for Git > ++# Git GUI - A graphical user interface for Git > + > -+Git Gui is a GUI for [git](https://git-scm.com/) written in Tcl/Tk. It > allows > -+you to use the git source control management tools via a G

Re: [PATCH v3 20/20] hashmap_entry: remove first member requirement from docs

Eric Wong writes: > Comments stating that "struct hashmap_entry" must be the first > member in a struct are no longer valid. > > Suggested-by: Phillip Wood > Signed-off-by: Eric Wong > --- > attr.c | 2 +- > builtin/fetch.c | 2 +- > hashmap.h | 4 ++-- >

Re: [PATCH v3] merge-recursive: fix the diff3 common ancestor label for virtual commits

Elijah Newren writes: > In commit 743474cbfa8b ("merge-recursive: provide a better label for > diff3 common ancestor", 2019-08-17), the label for the common ancestor > was changed from always being > > "merged common ancestors" > > to instead be based on the number of merge bases: > >

What's cooking in git.git (Oct 2019, #02; Mon, 7)

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: [PATCH] Feature: custom guitool commands can now have custom keyboard shortcuts

Hi Pratyush, Regarding your messages, >On Sun, 2019-10-06 at 02:31 +0530, Pratyush Yadav wrote: > You don't need to "set up" an email client with git-send-email. > git-send-email is an email client itself. Well, one which can only send > emails. For now, I am sticking with a mail client ( evolu

Re: [PATCH] Feature: custom guitool commands can now have custom keyboard shortcuts

Hi Johannes Schindelin, Regarding your messages, > However, it might not even need to put in _such_ a lot of work: in my > tests, `Control-,` worked just as well as `Control-comma`. To test this > for yourself, use this snippet (that is slightly modified from the > example at the bottom of https: