Re: [PATCH v2 08/14] revision.c: use commit-slab for show_source

Junio C Hamano writes: > Nguyễn Thái Ngọc Duy writes: > >> -refname = commit->util; >> +refname = *revision_sources_peek(_sources, commit); > > At first glance, I thought that the reason why this uses _peek() is > because the "sources" is expected

Re: [PATCH v2 08/14] revision.c: use commit-slab for show_source

Nguyễn Thái Ngọc Duy writes: > - refname = commit->util; > + refname = *revision_sources_peek(_sources, commit); At first glance, I thought that the reason why this uses _peek() is because the "sources" is expected to only sparsely be populated, perhaps because

Re: [PATCH v2 06/14] sequencer.c: use commit-slab to mark seen commits

Nguyễn Thái Ngọc Duy writes: > It's done so that commit->util can be removed. See more explanation in > the commit that removes commit->util. > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > sequencer.c | 12 +--- > 1 file changed, 9 insertions(+),

Re: [PATCH/RFC] completion: complete all possible -no-

On Tue, May 8, 2018 at 11:24 AM, Duy Nguyen wrote: > On Mon, Apr 23, 2018 at 7:36 AM, Eric Sunshine > wrote: >> I haven't looked at the implementation, so this may be an entirely >> stupid suggestion, but would it be possible to instead render the >>

Re: [PATCH 2/1] config: let `config_store_data_clear()` handle `value_regex`

On Sun, May 13, 2018 at 5:58 AM, Martin Ågren wrote: > Instead of carefully clearing up `value_regex` in each code path, let > `config_store_data_clear()` handle that. > > Signed-off-by: Martin Ågren > --- > I *think* that it should be ok to

Re: [PATCH] config: free resources of `struct config_store_data`

On Sun, May 13, 2018 at 5:58 AM, Martin Ågren wrote: > On 13 May 2018 at 10:59, Eric Sunshine wrote: >> On Sun, May 13, 2018 at 4:23 AM Martin Ågren wrote: >>> Introduce and use a small helper function

Re: [PATCH 2/2] apply: add --intent-to-add

Nguyễn Thái Ngọc Duy writes: > Similar to 'git reset -N', this option makes 'git apply' automatically > mark new files as intent-to-add so they are visible in the following > 'git diff' command and could also be committed with 'git commit -a'. > > Signed-off-by: Nguyễn Thái

Re: [PATCH 1/3] checkout.c: add strict usage of -- before file_path

Duy Nguyen writes: > > I would like an option to revert back to current behavior. I'm not a > new user. I know what I'm doing. Please don't make me type more. I can guarantee that nobody will stay a newbie. They either become more proficient and aware of what they are doing

Re: [PATCH] fast-export: avoid NULL pointer arithmetic

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. > > Or we could roll our own custom hash map, as I mused in an

Proposal

-- Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey

Re: [PATCH v2 04/14] describe: use commit-slab for commit names instead of commit->util

Nguyễn Thái Ngọc Duy writes: > + slot = commit_names_peek(_names, c); > + n = slot ? *slot : NULL; Seeing this and the helper in the previous step makes me wonder if we also want a "peek-and-then-peel" variant that encapsulates this pattern. We'll

Re: [PATCH v2 03/14] blame: use commit-slab for blame suspects instead of commit->util

Nguyễn Thái Ngọc Duy writes: > It's done so that commit->util can be removed. See more explanation in > the commit that removes commit->util. > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > blame.c | 42 +++--- >

Re: [PATCH v2 02/14] commit-slab: support shared commit-slab

Nguyễn Thái Ngọc Duy writes: > define_shared_commit_slab() could be used in a header file to define a > commit-slab. One of these C files must include commit-slab-impl.h and > "call" implement_shared_commit_slab(). > > Signed-off-by: Nguyễn Thái Ngọc Duy >

Re: [PATCH v2 01/14] commit-slab.h: code split

Nguyễn Thái Ngọc Duy writes: > The struct declaration and implementation macros are moved to > commit-slab-hdr.h and commit-slab-impl.h respectively. This right now > is not needed for current users but if we share a commit-slab for > multiple files, we need something better

Re: Re: [PATCH 1/3] checkout.c: add strict usage of -- before file_path

From: "Dannier Castro L" On 13/05/2018 00:03, Duy Nguyen wrote: On Sun, May 13, 2018 at 4:23 AM, Dannier Castro L wrote: For GIT new users, this complicated versatility of could be very confused, also considering that actually the flag '--' is

Proposal

-- Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey

Draft of Git Rev News edition 39

Hi, A draft of a new Git Rev News edition is available here: https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-39.md Everyone is welcome to contribute in any section either by editing the above page on GitHub and sending a pull request, or by commenting on this GitHub

Re: [PATCH 1/3] checkout.c: add strict usage of -- before file_path

On Sat, May 12, 2018 at 08:23:32PM -0600, Dannier Castro L wrote: > Currently, is a complex command able to handle both > branches and files without any distintion other than their names, > taking into account that depending on the type (branch or file), > the functionality is completely

Re: Re: [PATCH 1/3] checkout.c: add strict usage of -- before file_path

> On 13/05/2018 00:03, Duy Nguyen wrote: > > > On Sun, May 13, 2018 at 4:23 AM, Dannier Castro L > > wrote: > >> For GIT new users, this complicated versatility of could > >> be very confused, also considering that actually the flag '--' is > >> completely useless (added

Re: Re: [PATCH 1/3] checkout.c: add strict usage of -- before file_path

On 13/05/2018 00:03, Duy Nguyen wrote: On Sun, May 13, 2018 at 4:23 AM, Dannier Castro L wrote: For GIT new users, this complicated versatility of could be very confused, also considering that actually the flag '--' is completely useless (added or not, there is not any

Re: [PATCH] config: free resources of `struct config_store_data`

On 13 May 2018 at 10:23, Martin Ågren wrote: > +void config_store_data_clear(struct config_store_data *store) I will do s/void/static void/ here...

Re: [PATCH 01/18] Add a function to solve least-cost assignment problems

On Thu, May 3, 2018 at 5:30 PM, Johannes Schindelin wrote: > + /* reduction transfer */ > + free_row = xmalloc(sizeof(int) * row_count); > + for (int i = 0; i < row_count; i++) { travis complains about this hungarian.c: In function

[PATCH 1/2] diff: turn --ita-invisible-in-index on by default

Due to the implementation detail of intent-to-add entries. The current "git diff" (i.e. no treeish or --cached argument) would show the changes in the i-t-a file, but it does not mark the file as new, while "diff --cached" would mark the file as new while showing its content as empty. One

[PATCH 2/2] apply: add --intent-to-add

Similar to 'git reset -N', this option makes 'git apply' automatically mark new files as intent-to-add so they are visible in the following 'git diff' command and could also be committed with 'git commit -a'. Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/git-apply.txt

Re: [PATCH v2 17/28] t4014: abstract away SHA-1-specific constants

On Sun, May 13, 2018 at 09:34:03AM +0200, Johannes Sixt wrote: > Am 13.05.2018 um 04:24 schrieb brian m. carlson: > > diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh > > index dac3f349a3..42b3e11207 100755 > > --- a/t/t4014-format-patch.sh > > +++ b/t/t4014-format-patch.sh > > @@

Re: [PATCH 1/3] checkout.c: add strict usage of -- before file_path

"Dannier Castro L" wrote: > Currently, is a complex command able to handle both > branches and files without any distintion other than their names, > taking into account that depending on the type (branch or file), > the functionality is completely different, the easier

Re: [PATCH] travis-ci: run gcc-7 on linux-gcc jobs

Am 13.05.2018 um 11:17 schrieb Nguyễn Thái Ngọc Duy: > Switch from gcc-4.8 to gcc-7. Newer compilers come with more warning > checks (usually in -Wextra). Since -Wextra is enabled in developer > mode (which is also enabled in travis), this lets travis report more > warnings before other people do

[PATCH v1 1/8] fetch-object: make functions return an error code

The callers of the fetch_object() and fetch_objects() might be interested in knowing if these functions succeeded or not. Signed-off-by: Christian Couder --- fetch-object.c | 15 +-- fetch-object.h | 6 +++--- sha1-file.c| 4 ++-- 3 files changed, 14

[PATCH v1 6/8] Use odb_remote_get_direct() and has_external_odb()

Instead of using the repository_format_partial_clone global and fetch_object() directly, let's use has_odb_remote() and odb_remote_get_direct(). Signed-off-by: Christian Couder --- builtin/cat-file.c| 5 +++-- builtin/fetch.c | 11 ++-

[PATCH v1 8/8] t0410: test fetching from many promisor remotes

Signed-off-by: Christian Couder --- t/t0410-partial-clone.sh | 24 +++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/t/t0410-partial-clone.sh b/t/t0410-partial-clone.sh index 6af4712da8..4a7a662512 100755 ---

[PATCH v1 7/8] Use odb.origin.partialclonefilter instead of core.partialclonefilter

Let's make the partial clone filter specific to one odb instead of general to all the odbs. This makes it possible to have different partial clone filters for different odbs. Signed-off-by: Christian Couder --- builtin/fetch.c | 2 +-

[PATCH v1 4/8] odb-remote: implement odb_remote_get_many_direct()

This function will be used to get many objects from a promisor remote. Signed-off-by: Christian Couder --- odb-helper.c | 15 +++ odb-helper.h | 3 +++ odb-remote.c | 17 + odb-remote.h | 1 + 4 files changed, 36 insertions(+) diff --git

[PATCH v1 3/8] odb-remote: implement odb_remote_get_direct()

This is implemented only in the promisor remote mode for now by calling fetch_object(). Signed-off-by: Christian Couder --- odb-helper.c | 14 ++ odb-helper.h | 3 ++- odb-remote.c | 17 + odb-remote.h | 1 + 4 files changed, 34

[PATCH v1 2/8] Add initial odb remote support

The odb-remote.{c,h} files will contain the functions that are called by the rest of Git mostly from "sha1_file.c" to access the objects managed by the odb remotes. The odb-helper.{c,h} files will contain the functions to actually implement communication with either the internal functions or the

[PATCH v1 5/8] odb-remote: add odb_remote_reinit()

We will need to reinitialize the odb remote configuration as we will make some changes to it in a later commit when we will detect that a remote is also an odb remote. Signed-off-by: Christian Couder --- odb-remote.c | 14 -- odb-remote.h | 1 + 2 files

[PATCH v1 0/8] Introducing odb remote

This is a follow up from the patch series called "Promisor remotes and external ODB support" that I sent earlier this year. Following discussions of these patch series, where Junio said "a minimum s/ext/remote/ would clarify what it is", I decided to rename "external odb" to "odb remote". I am

Re: [PATCH] config: free resources of `struct config_store_data`

On 13 May 2018 at 10:59, Eric Sunshine wrote: > On Sun, May 13, 2018 at 4:23 AM Martin Ågren wrote: > >> Introduce and use a small helper function `config_store_data_clear()` to >> plug these leaks. This should be safe. The memory tracked here is

[PATCH 3/1] config: let `config_store_data_clear()` handle `key`

Instead of carefully clearing up `key` in each code path, let `config_store_data_clear()` handle that. We still need to free it before replacing it, though. Move that freeing closer to the replacing to be safe. Note that in that same part of the code, we can no longer set `key` to the original

[PATCH 2/1] config: let `config_store_data_clear()` handle `value_regex`

Instead of carefully clearing up `value_regex` in each code path, let `config_store_data_clear()` handle that. Signed-off-by: Martin Ågren --- I *think* that it should be ok to `regfree()` after `regcomp()` failed, but I'll need to look into that some more (and say

[PATCH] travis-ci: run gcc-7 on linux-gcc jobs

Switch from gcc-4.8 to gcc-7. Newer compilers come with more warning checks (usually in -Wextra). Since -Wextra is enabled in developer mode (which is also enabled in travis), this lets travis report more warnings before other people do it. Signed-off-by: Nguyễn Thái Ngọc Duy

Re: [PATCH] config: free resources of `struct config_store_data`

On Sun, May 13, 2018 at 4:23 AM Martin Ågren wrote: > Commit fee8572c6d (config: avoid using the global variable `store`, > 2018-04-09) dropped the staticness of a certain struct, instead letting > the users create an instance on the stack and pass around a pointer. > We

[PATCH] config: free resources of `struct config_store_data`

Commit fee8572c6d (config: avoid using the global variable `store`, 2018-04-09) dropped the staticness of a certain struct, instead letting the users create an instance on the stack and pass around a pointer. We do not free the memory that the struct tracks. When the struct was static, the memory

Re: [PATCH v2 17/28] t4014: abstract away SHA-1-specific constants

Am 13.05.2018 um 04:24 schrieb brian m. carlson: Adjust the test so that it computes values for blobs instead of using hard-coded hashes. Signed-off-by: brian m. carlson --- t/t4014-format-patch.sh | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-)

Re: [PATCH v7 12/13] completion: let git provide the completable command list

On Fri, May 11, 2018 at 5:05 PM, SZEDER Gábor wrote: > On Thu, May 10, 2018 at 10:46 AM, Nguyễn Thái Ngọc Duy > wrote: >> Instead of maintaining a separate list of command classification, >> which often could go out of date, let's centralize the

Re: [PATCH 1/3] checkout.c: add strict usage of -- before file_path

On Sun, May 13, 2018 at 4:23 AM, Dannier Castro L wrote: > Currently, is a complex command able to handle both > branches and files without any distintion other than their names, > taking into account that depending on the type (branch or file), > the functionality is