Re: [PATCH v2 6/6] revision.c: refactor basic topo-order logic

On Tue, Sep 18 2018, Derrick Stolee via GitGitGadget wrote: > diff --git a/revision.h b/revision.h > index fd4154ff75..b20c16c0e0 100644 > --- a/revision.h > +++ b/revision.h > @@ -24,6 +24,8 @@ > #define USER_GIVEN (1u<<25) /* given directly by the user */ > #define TRACK_LINEAR (1u<<26) >

[PATCH 0/3] doc: fixups for ab/fetch-tags-noclobber

Of course I only noticed these after the series had landed in master... Ævar Arnfjörð Bjarmason (3): push doc: add spacing between two words fetch doc: correct grammar in --force docs fetch doc: correct grammar in --force docs Documentation/git-push.txt | 2 +-

[PATCH 2/3] fetch doc: correct grammar in --force docs

Correct a grammar error (saying "the receiving" made no sense) in the recently landed documentation added in my 0bc8d71b99 ("fetch: stop clobbering existing tags without --force", 2018-08-31) by rephrasing the sentence. Signed-off-by: Ævar Arnfjörð Bjarmason ---

[PATCH 1/3] push doc: add spacing between two words

Fix a formatting error introduced in my recently landed fe802bd21e ("push doc: correct lies about how push refspecs work", 2018-08-31). Signed-off-by: Ævar Arnfjörð Bjarmason --- Documentation/git-push.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 3/3] fetch doc: correct grammar in --force docs

"Work the same" is incorrect and needs to be "Works the same way". Fixes grammar in document anion I added in the recently landed 0bc8d71b99 ("fetch: stop clobbering existing tags without --force", 2018-08-31). Signed-off-by: Ævar Arnfjörð Bjarmason --- Documentation/pull-fetch-param.txt | 2 +-

[PATCH] config doc: add missing list separator for checkout.optimizeNewBranch

The documentation added in fa655d8411 ("checkout: optimize "git checkout -b "", 2018-08-16) didn't add the double-colon needed for the labeled list separator, as a result the added documentation all got squashed into one paragraph. Fix that by adding the list separator. Signed-off-by: Ævar

Cannot negate `*` ignore pattern for directory with space in the name

To reproduce (from ): $ cd "$(mktemp --directory)" $ mkdir foo\ bar $ touch foo\ bar/test $ git init Initialized empty Git repository in /tmp/tmp.iGmBR6y2xR/.git/ $ git status --short ?? foo bar/ $ cat > .gitignore << EOF > * > !foo bar > !foo\ bar >

[PATCH v2 5/6] commit/revisions: bookkeeping before refactoring

From: Derrick Stolee There are a few things that need to move around a little before making a big refactoring in the topo-order logic: 1. We need access to record_author_date() and compare_commits_by_author_date() in revision.c. These are used currently by sort_in_topological_order() in

[PATCH v2 0/6] Use generation numbers for --topo-order

This patch series performs a decently-sized refactoring of the revision-walk machinery. Well, "refactoring" is probably the wrong word, as I don't actually remove the old code. Instead, when we see certain options in the 'rev_info' struct, we redirect the commit-walk logic to a new set of methods

[PATCH v2 3/6] test-reach: add rev-list tests

From: Derrick Stolee The rev-list command is critical to Git's functionality. Ensure it works in the three commit-graph environments constructed in t6600-test-reach.sh. Here are a few important types of rev-list operations: * Basic: git rev-list --topo-order HEAD * Range: git rev-list

[PATCH v2 1/6] prio-queue: add 'peek' operation

From: Derrick Stolee When consuming a priority queue, it can be convenient to inspect the next object that will be dequeued without actually dequeueing it. Our existing library did not have such a 'peek' operation, so add it as prio_queue_peek(). Add a reference-level comparison in

[PATCH v2 6/6] revision.c: refactor basic topo-order logic

From: Derrick Stolee When running a command like 'git rev-list --topo-order HEAD', Git performed the following steps: 1. Run limit_list(), which parses all reachable commits, adds them to a linked list, and distributes UNINTERESTING flags. If all unprocessed commits are UNINTERESTING,

[PATCH v2 4/6] revision.c: begin refactoring --topo-order logic

From: Derrick Stolee When running 'git rev-list --topo-order' and its kin, the topo_order setting in struct rev_info implies the limited setting. This means that the following things happen during prepare_revision_walk(): * revs->limited implies we run limit_list() to walk the entire

[PATCH v2 2/6] test-reach: add run_three_modes method

From: Derrick Stolee The 'test_three_modes' method assumes we are using the 'test-tool reach' command for our test. However, we may want to use the data shape of our commit graph and the three modes (no commit-graph, full commit-graph, partial commit-graph) for other git commands. Split

Re: [PATCH v2 6/6] t9109-git-svn-props.sh: split up several pipes

On Mon, Sep 17, 2018 at 6:25 PM Matthew DeVore wrote: > t9109-git-svn-props.sh: split up several pipes Similar to my comment about 5/6, this title talks about the mechanical changes made by the patch but not the intent. Perhaps reword it like this: t9109: avoid swallowing Git exit code

Re: [PATCH] t5551-http-fetch-smart.sh: sort cookies before comparing

Jeff King writes: >> -cat >expect_cookies.txt <> +cat > This can be spelled: > > sort >expect_cookies.txt < > can't it? Then we do not even incur the extra process. :) Yeah, true. Running cat only to feed a pipe with contents of a single file or the here-doc is an

Re: [PATCH v2 5/6] tests: split up pipes

On Mon, Sep 17, 2018 at 6:25 PM Matthew DeVore wrote: > tests: split up pipes This title explains the mechanical changes the patch is making but not the intent. Perhaps reword it to say something like: tests: avoid swallowing Git exit code upstream of a pipe > Some pipes in tests lose the

Re: [PATCH v2 4/6] tests: Add linter check for pipe placement style

On Mon, Sep 17, 2018 at 6:25 PM Matthew DeVore wrote: > tests: Add linter check for pipe placement style Until now, the various "lint" checks have been for genuine portability problems (except perhaps 'test-lint-duplicates'). This new lint check makes style violations worthy of failing "make

Re: [PATCH v2 1/6] CodingGuidelines: add shell piping guidelines

On Mon, Sep 17, 2018 at 6:24 PM Matthew DeVore wrote: > diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines > @@ -163,6 +163,35 @@ For shell scripts specifically (not exhaustive): > + - In a piped sequence which spans multiple lines, put each statement > + on a separate

Re: [PATCH] Add an EditorConfig file

Hi brian, Thanks for CC-ing me on this. I use editorconfig every day via the configuration in my home directory [1], and the Vim plugin editorconfig-vim [2]. It's a great piece of software, and I've been using it without any issue since around the beginning of 2015. On Mon, Sep 17, 2018 at

[PATCH] Add an EditorConfig file

Contributors to Git use a variety of editors, each with their own configuration files. Because C lacks the defined norms on how to indent and style code that other languages, such as Ruby and Rust, have, it's possible for various contributors, especially new ones, to have configured their editor

Offre de prêts

Bonjour Vous aviez besoin de prêts d'argent entre particuliers pour faire face aux difficultés financières pour enfin sortir de l'impasse que provoquent les banques, par le rejet de vos dossiers de demande de crédits ? Je suis un citoyen français à la retraite en mesure de vous faire un prêt de

Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)

Junio C Hamano writes: > The tip of 'next' hasn't been rewound yet, but the states of many > topics that were marked to "Cook in 'next'" read "Will merge to > 'master'" now. I'll probably start merging a handful of topics that > have been in 'next' down to 'master' tonight (they appear at the >

RE: [Question] Alternative to git-lfs under go

On September 17, 2018 6:02 PM, Jonathan Nieder wrote: > Randall S. Becker wrote: > > On September 17, 2018 3:28 PM, Jonathan Nieder wrote: > >> Randall S. Becker wrote: > > >>> Does anyone know whether it is practical to rework git-lfs under a > >>> language other than "go"? GCC is not even close

Re: [PATCH] t5551-http-fetch-smart.sh: sort cookies before comparing

On Mon, Sep 17, 2018 at 02:45:55PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > Yes, I think sorting the expect file would work fine. I'm OK with that, > > or just leaving a comment. The comment has the bonus that it does not > > cost an extra process at runtime. I'd probably use a

[PATCH v2 5/6] tests: split up pipes

Some pipes in tests lose the exit code of git processes, which can mask unexpected behavior. Split these pipes up so that git commands are at the end of pipes rather than the beginning or middle. --- t/t5317-pack-objects-filter-objects.sh | 156 + t/t5500-fetch-pack.sh

[PATCH v2 3/6] t/*: fix ordering of expected/observed arguments

Fix various places where the ordering was obviously wrong, meaning it was easy to find with grep. Signed-off-by: Matthew DeVore --- t/t-basic.sh | 2 +- t/t0021-conversion.sh | 4 +-- t/t1300-config.sh | 4 +--

[PATCH v2 2/6] tests: standardize pipe placement

Instead of using a line-continuation and pipe on the second line, take advantage of the shell's implicit line continuation after a pipe character. So for example, instead of some long line \ | next line use some long line | next line And add a blank

[PATCH v2 1/6] CodingGuidelines: add shell piping guidelines

Add two guidelines: - pipe characters should appear at the end of lines, and not cause indentation - pipes should be avoided when they swallow exit codes that can potentially fail --- Documentation/CodingGuidelines | 29 + 1 file changed, 29 insertions(+)

[PATCH v2 6/6] t9109-git-svn-props.sh: split up several pipes

A test uses several separate pipe sequences in a row which are awkward to split up. Wrap the split-up pipe in a function so the awkwardness is not repeated. Signed-off-by: Matthew DeVore --- t/t9101-git-svn-props.sh | 21 + 1 file changed, 13 insertions(+), 8 deletions(-)

[PATCH v2 4/6] tests: add linter check for pipe placement style

--- t/Makefile | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/t/Makefile b/t/Makefile index c83fd1886..4eceabbd5 100644 --- a/t/Makefile +++ b/t/Makefile @@ -78,7 +78,7 @@ check-chainlint: done && exit $$err test-lint: test-lint-duplicates

[PATCH v2 4/6] tests: Add linter check for pipe placement style

--- t/Makefile | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/t/Makefile b/t/Makefile index c83fd1886..4eceabbd5 100644 --- a/t/Makefile +++ b/t/Makefile @@ -78,7 +78,7 @@ check-chainlint: done && exit $$err test-lint: test-lint-duplicates

[PATCH v2 0/6] Clean up tests for test_cmp arg ordering and pipe placement

This applies the suggestions from jrn@'s response to v1 here: https://public-inbox.org/git/20180917163137.gb89...@aiede.svl.corp.google.com/ The major changes are: - Added two bullet points to Documentation/CodingGuidelines about 1) how to format pipe sequences and 2) using temporary files

RE: [Question] Alternative to git-lfs under go

On September 17, 2018 6:01 PM, Taylor Blau wrote: > On Mon, Sep 17, 2018 at 05:55:55PM -0400, Randall S. Becker wrote: > > On September 17, 2018 3:28 PM, Jonathan Nieder wrote: > > > Randall S. Becker wrote: > > > > > > > Does anyone know whether it is practical to rework git-lfs under a > > > >

Re: [PATCH] mailmap: consistently normalize brian m. carlson's name

On Mon, Sep 17, 2018 at 11:18:00AM -0700, Jonathan Nieder wrote: > v2.18.0-rc0~70^2 (mailmap: update brian m. carlson's email address, > 2018-05-08) changed the mailmap to map > > sand...@crustytoothpaste.ath.cx >-> brian m. carlson > > instead of > > sand...@crustytoothpaste.net >

Re: [Question] Alternative to git-lfs under go

(+cc: Taylor Blau, git-lfs expert) Randall S. Becker wrote: > On September 17, 2018 3:28 PM, Jonathan Nieder wrote: >> Randall S. Becker wrote: >>> Does anyone know whether it is practical to rework git-lfs under a >>> language other than "go"? GCC is not even close to being possible to >>> port

Re: [Question] Alternative to git-lfs under go

Hi Randall, On Mon, Sep 17, 2018 at 05:55:55PM -0400, Randall S. Becker wrote: > On September 17, 2018 3:28 PM, Jonathan Nieder wrote: > > Randall S. Becker wrote: > > > > > Does anyone know whether it is practical to rework git-lfs under a > > > language other than "go"? GCC is not even close to

RE: [Question] Alternative to git-lfs under go

On September 17, 2018 3:28 PM, Jonathan Nieder wrote: > Randall S. Becker wrote: > > > Does anyone know whether it is practical to rework git-lfs under a > > language other than "go"? GCC is not even close to being possible to > > port to my NonStop platform (may have tried, some have died - joke

Re: [PATCH v1 1/2] t/*: fix pipe placement and remove \'s

On Mon, Sep 17, 2018 at 9:31 AM Jonathan Nieder wrote: > > Matthew DeVore wrote: > > > Subject: t/*: fix pipe placement and remove \'s > > > > Where ever there was code in the tests like this: > > > > foo \ > > | bar > > Language nits: > - s/Where ever/Wherever/ > - Git's

[PATCH v2 2/2] t5551: compare sorted cookies files

In t5551 we check that we save cookies correctly to a file when http.cookiefile and http.savecookies are set. To do so we create an expect file that expects the cookies in a certain order. However after e2ef8d6fa ("cookies: support creation-time attribute for cookies", 2018-08-28) in curl.git

[PATCH v2 0/2] t5551: compare sorted cookies files

Thanks Jonathan and Junio for the comments on the first round. Changes since the first round: - add a preparatory patch to modernize the test script - add Reported-by to credit Todd - just use 'sort' instead of 'cat | sort' Thomas Gummerer (2): t5551: move setup code inside test_expect blocks

[PATCH v2 1/2] t5551: move setup code inside test_expect blocks

Move setup code inside test_expect blocks, to catch unexpected failures in the setup steps, and bring the test scripts in line with our modern test style. Suggested-by: Jonathan Nieder Signed-off-by: Thomas Gummerer --- t/t5551-http-fetch-smart.sh | 66 ++--- 1

Re: [PATCH] t5551-http-fetch-smart.sh: sort cookies before comparing

Jeff King writes: > Yes, I think sorting the expect file would work fine. I'm OK with that, > or just leaving a comment. The comment has the bonus that it does not > cost an extra process at runtime. I'd probably use a sort if we expected > the list to be long and complicated, since it makes

Re: [PATCH 2/9] sha1-array: provide oid_array_filter

On Mon, Sep 17, 2018 at 2:36 PM Stefan Beller wrote: > > Helped-by: Junio C Hamano > Signed-off-by: Stefan Beller > --- > sha1-array.c | 17 + > sha1-array.h | 9 + > 2 files changed, 26 insertions(+) > > diff --git a/sha1-array.c b/sha1-array.c > index

[PATCH 5/9] submodule: move global changed_submodule_names into fetch submodule struct

The `changed_submodule_names` are only used for fetching, so let's make it part of the struct that is passed around for fetching submodules. Signed-off-by: Stefan Beller --- submodule.c | 42 +++--- 1 file changed, 23 insertions(+), 19 deletions(-) diff

[PATCH 6/9] submodule.c: do not copy around submodule list

'calculate_changed_submodule_paths' uses a local list to compute the changed submodules, and then produces the result by copying appropriate items into the result list. Instead use the result list directly and prune items afterwards using string_list_remove_empty_items. By doing so we'll have

[PATCH 8/9] fetch: retry fetching submodules if needed objects were not fetched

Currently when git-fetch is asked to recurse into submodules, it dispatches a plain "git-fetch -C " (with some submodule related options such as prefix and recusing strategy, but) without any information of the remote or the tip that should be fetched. This works surprisingly well in some

[PATCH 7/9] submodule: fetch in submodules git directory instead of in worktree

This patch started as a refactoring to make 'get_next_submodule' more readable, but upon doing so, I realized that "git fetch" of the submodule actually doesn't need to be run in the submodules worktree. So let's run it in its git dir instead. That should pave the way towards fetching submodules

[PATCH 9/9] builtin/fetch: check for submodule updates for non branch fetches

Gerrit, the code review tool, has a different workflow than our mailing list based approach. Usually users upload changes to a Gerrit server and continuous integration and testing happens by bots. Sometimes however a user wants to checkout a change locally and look at it locally. For this use

[PATCH 2/9] sha1-array: provide oid_array_filter

Helped-by: Junio C Hamano Signed-off-by: Stefan Beller --- sha1-array.c | 17 + sha1-array.h | 9 + 2 files changed, 26 insertions(+) diff --git a/sha1-array.c b/sha1-array.c index 265941fbf40..67db5eeec9a 100644 --- a/sha1-array.c +++ b/sha1-array.c @@ -77,3 +77,20 @@

[PATCHv2 0/9] fetch: make sure submodule oids are fetched

v2: * extended commit messages, * plugged a memory leak * rewrote the patch "sha1-array: provide oid_array_filter" to be much more like object_array_fiter * fixed a typo pointed out by Ramsay. The range diff is below. Thanks, Stefan v1: Currently when git-fetch is asked to recurse into

[PATCH 3/9] submodule.c: fix indentation

The submodule subsystem is really bad at staying within 80 characters. Fix it while we are here. Signed-off-by: Stefan Beller --- submodule.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/submodule.c b/submodule.c index a2b266fbfae..d29dfa3d1f5 100644 ---

[PATCH 4/9] submodule.c: sort changed_submodule_names before searching it

We can string_list_insert() to maintain sorted-ness of the list as we find new items, or we can string_list_append() to build an unsorted list and sort it at the end just once. To pick which one is more appropriate, we notice the fact that we discover new items more or less in the already sorted

[PATCH 1/9] string-list: add string_list_{pop, last} functions

Add a few functions to allow a string-list to be used as a stack: - string_list_last() lets a caller peek the string_list_item at the end of the string list. The caller needs to be aware that it is borrowing a pointer, which can become invalid if/when the string_list is resized. -

Re: [PATCH v5 2/5] read-cache: load cache extensions on a worker thread

Duy Nguyen writes: >> diff --git a/read-cache.c b/read-cache.c >> index 858935f123..b203eebb44 100644 >> --- a/read-cache.c >> +++ b/read-cache.c >> @@ -23,6 +23,10 @@ >> #include "split-index.h" >> #include "utf8.h" >> #include "fsmonitor.h" >> +#ifndef NO_PTHREADS >> +#include >> +#include

Re: [PATCH] t5551: compare sorted cookies files

Thomas Gummerer wrote: > On 09/17, Junio C Hamano wrote: >> The other >> effort implicitly depends on the expected output is kept sorted, but >> this one is more explicit---I tend to prefer this approach as tools >> and automation is easier

Re: [PATCH] t5551: compare sorted cookies files

On 09/17, Junio C Hamano wrote: > Thomas Gummerer writes: > > > In t5551 we check that we save cookies correctly to a file when > > http.cookiefile and http.savecookies are set. To do so we create an > > expect file that expects the cookies in a certain order. > > > > However after e2ef8d6fa

Re: [PATCH 3/3] doc/Makefile: drop doc-diff worktree and temporary files on "make clean"

On Mon, Sep 17, 2018 at 4:43 PM Eric Sunshine wrote: > I did consider this case and felt that it would be reasonable for it > to error out and ignore the error if git was missing or if the > directory was not a repository. And, I _thought_ I had prefixed the > line with "-" to handle just such a

Re: [PATCH] midx.c: mark a file-local symbol as static

Derrick Stolee writes: > Thanks for catching this, Ramsay. Sorry for the mistake. > > ds/multi-pack-verify is currently queued for 'next', so I wasn't > planning on sending another version. Marked for 'next' does not mean we cannot touch it. It merely means "so far no issue that requires a

Re: [PATCH] midx.c: mark a file-local symbol as static

Derrick Stolee writes: > ds/multi-pack-verify is currently queued for 'next', so I wasn't > planning on sending another version. > > Junio, could you add this commit to the tip, or squash it into > 64cbf3df2 "multi-pack-index: add 'verify' verb"? I think it makes sense to queue this on top.

Re: [PATCH 3/3] doc/Makefile: drop doc-diff worktree and temporary files on "make clean"

On Mon, Sep 17, 2018 at 3:36 PM Junio C Hamano wrote: > Jonathan Nieder writes: > >> +'$(SHELL_PATH_SQ)' ./doc-diff --clean > > > > This means I need a copy of git in order to run "make clean". That > > was never required before. It makes bootstrapping difficult --- do we > > really need

git pull --rebase=preserve is always rebasing something, even on up-to-date branch

Please try the following: mmatrosov@Mikhail-PC:~/test$ git init --bare server Initialized empty Git repository in /home/mmatrosov/test/server/ mmatrosov@Mikhail-PC:~/test$ git clone server local Cloning into 'local'... warning: You appear to have cloned an empty repository. done.

Re: [PATCH] midx.c: mark a file-local symbol as static

On 9/14/2018 7:26 PM, Ramsay Jones wrote: Signed-off-by: Ramsay Jones --- Hi Derrick, If you need to re-roll your 'ds/multi-pack-verify' branch, could you please squash this into the relevant patch (commit 64cbf3df21, "multi-pack-index: add 'verify' verb", 2018-09-13). [noticed by sparse].

Re: [PATCH] t5551: compare sorted cookies files

Thomas Gummerer writes: > In t5551 we check that we save cookies correctly to a file when > http.cookiefile and http.savecookies are set. To do so we create an > expect file that expects the cookies in a certain order. > > However after e2ef8d6fa ("cookies: support creation-time attribute for >

Re: [PATCH 3/3] doc/Makefile: drop doc-diff worktree and temporary files on "make clean"

Junio C Hamano wrote: > Jonathan Nieder writes: >> I'd rather that we revert this change altogether. I have nothing >> against a convenient command to do this kind of non build related >> cleanup, but it shouldn't be spelled as "make clean". > > OK, let's do this for now as I wanted to merge

Re: [PATCH 3/3] doc/Makefile: drop doc-diff worktree and temporary files on "make clean"

Jonathan Nieder writes: > I'd rather that we revert this change altogether. I have nothing > against a convenient command to do this kind of non build related > cleanup, but it shouldn't be spelled as "make clean". OK, let's do this for now as I wanted to merge the remainder to 'master' today.

Re: [PATCH 3/3] doc/Makefile: drop doc-diff worktree and temporary files on "make clean"

Junio C Hamano wrote: > Jonathan Nieder writes: >> Eric Sunshine wrote: >>> + '$(SHELL_PATH_SQ)' ./doc-diff --clean >> >> This means I need a copy of git in order to run "make clean". That >> was never required before. It makes bootstrapping difficult --- do we >> really need it? > > Gahh,

Re: [PATCH 3/3] doc/Makefile: drop doc-diff worktree and temporary files on "make clean"

Jonathan Nieder writes: >> +'$(SHELL_PATH_SQ)' ./doc-diff --clean > > This means I need a copy of git in order to run "make clean". That > was never required before. It makes bootstrapping difficult --- do we > really need it? Gahh, you are absolutely right. Also "doc-diff --clean", if I

Re: [Question] Alternative to git-lfs under go

Hi, Randall S. Becker wrote: > Does anyone know whether it is practical to rework git-lfs under a language > other than "go"? GCC is not even close to being possible to port to my > NonStop platform (may have tried, some have died - joke - trying). I would > like to convert this directly to C

Re: [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content

Duy Nguyen writes: > On Mon, Sep 17, 2018 at 7:09 PM Junio C Hamano wrote: >> ... >> On the other hand, if I am keeping some change that should never be >> in a commit in the working tree file, and building the contents in >> the index using "add -p" to incrementally, it would be the same >>

[Question] Alternative to git-lfs under go

Hi All, Does anyone know whether it is practical to rework git-lfs under a language other than "go"? GCC is not even close to being possible to port to my NonStop platform (may have tried, some have died - joke - trying). I would like to convert this directly to C or something more widely

[PATCH] t5551: compare sorted cookies files

In t5551 we check that we save cookies correctly to a file when http.cookiefile and http.savecookies are set. To do so we create an expect file that expects the cookies in a certain order. However after e2ef8d6fa ("cookies: support creation-time attribute for cookies", 2018-08-28) in curl.git

Re: [PATCH v4 02/23] read-cache.c: remove 'const' from index_has_changes()

Duy Nguyen writes: > On Mon, Sep 17, 2018 at 6:25 PM Junio C Hamano wrote: >> >> Nguyễn Thái Ngọc Duy writes: >> >> > This function calls do_diff_cache() which eventually needs to set this >> > "istate" to unpack_options->src_index (*). This is an unfortunate fact >> > that unpack_trees()

Re: [PATCH v5 1/5] eoie: add End of Index Entry (EOIE) extension

Duy Nguyen writes: > I get annoyed by the "ignoring unknown extension xxx" messages while > testing though (not just this extension) and I think it will be the > same for other git implementations. But perhaps other implementations > just silently drop the extension. Most of the extensions we

Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)

Derrick Stolee writes: >> Replaced with a newer version. > > I think this has been the same note for a few weeks now. What does it > mean? Did I send a new version out that you haven't picked up? It just means that I didn't bother to look at the current status message for the topic that had

Re: [PATCH v5 3/5] read-cache: load cache entries on worker threads

On 9/15/2018 7:09 AM, Duy Nguyen wrote: On Sat, Sep 15, 2018 at 01:07:46PM +0200, Duy Nguyen wrote: 12:50:00.084237 read-cache.c:1721 start loading index 12:50:00.119941 read-cache.c:1943 performance: 0.034778758 s: loaded all extensions (1667075 bytes) 12:50:00.185352

Re: [PATCH v2] linear-assignment: fix potential out of bounds memory access

Thomas Gummerer wrote: > Currently the 'compute_assignment()' function may read memory out > of bounds, even if used correctly. Namely this happens when we only > have one column. [...] > Reported-by: ryenus > Helped-by: Derrick Stolee > Signed-off-by: Thomas Gummerer > --- >

Re: [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content

On Mon, Sep 17, 2018 at 8:15 PM Jeff King wrote: > On Mon, Sep 17, 2018 at 07:29:26PM +0200, Duy Nguyen wrote: > > I don't see a good way to get to recover this situation. I could go > > back to the "index log" idea, where we keep a log of index changes (or > > just "interesting" changes). That

Re: [PATCH 2/3] gc: exit with status 128 on failure

Hi, Jeff King wrote: > On Tue, Jul 17, 2018 at 03:59:47PM -0400, Jeff King wrote: >> On Mon, Jul 16, 2018 at 11:54:16PM -0700, Jonathan Nieder wrote: >>> A value of -1 returned from cmd_gc gets propagated to exit(), >>> resulting in an exit status of 255. Use die instead for a clearer >>> error

Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)

On 9/14/2018 5:56 PM, Junio C Hamano wrote: * ds/format-commit-graph-docs (2018-08-21) 2 commits - commit-graph.txt: improve formatting for asciidoc - Docs: Add commit-graph tech docs to Makefile Design docs for the commit-graph machinery is now made into HTML as well as text. Will

Re: [PATCH 2/3] gc: exit with status 128 on failure

On Tue, Jul 17, 2018 at 03:59:47PM -0400, Jeff King wrote: > On Mon, Jul 16, 2018 at 11:54:16PM -0700, Jonathan Nieder wrote: > > > A value of -1 returned from cmd_gc gets propagated to exit(), > > resulting in an exit status of 255. Use die instead for a clearer > > error message and a

Re: [PATCH 3/3] doc/Makefile: drop doc-diff worktree and temporary files on "make clean"

Hi, Eric Sunshine wrote: > doc-diff creates a temporary working tree (git-worktree) and generates a > bunch of temporary files which it does not remove since they act as a > cache to speed up subsequent runs. Although doc-diff's working tree and > generated files are not strictly build products

Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)

Jeff King wrote: > Let me inject some more uncertainty, then. ;) > > If we are not going to do 3/3, then should 2/3 simply avoid passing "-1" > back via return from main? I guess I don't have a strong opinion, but > one of the things I noted was that we converted those die() calls > introduced in

Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)

On Mon, Sep 17, 2018 at 10:51:35AM -0700, Junio C Hamano wrote: > Jeff King writes: > > >> > What's the donness of this one? > >> > cf. <20180717201348.gd26...@sigill.intra.peff.net> > >> > >> This topic has stayed in 'pu' for a long time. I thought it was > >> concluded that this was a good

[PATCH] mailmap: consistently normalize brian m. carlson's name

v2.18.0-rc0~70^2 (mailmap: update brian m. carlson's email address, 2018-05-08) changed the mailmap to map sand...@crustytoothpaste.ath.cx -> brian m. carlson instead of sand...@crustytoothpaste.net -> brian m. carlson That means the mapping Brian M. Carlson -> brian m.

Re: [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content

On Mon, Sep 17, 2018 at 07:29:26PM +0200, Duy Nguyen wrote: > > On the other hand, if I am keeping some change that should never be > > in a commit in the working tree file, and building the contents in > > the index using "add -p" to incrementally, it would be the same > > disaster as you are

Re: Brandon Williams's E-Mail bouncing

On Mon, Sep 17, 2018 at 10:51 AM Ævar Arnfjörð Bjarmason wrote: > > Aside from that particular address bouncing [...] it would be nice if git > {format-patch,send-email,check-contacts} & the .mailmap format would > support and understand some way to map addresses to > e.g. nore...@example.com,

Brandon Williams's E-Mail bouncing

[Sorry about the double send in private, forgot to CC the list] On Mon, Sep 17 2018, Duy Nguyen wrote: > Brandon, b0db704652[...] I noticed a few days ago that CC's to bmw...@google.com bounce. Has he left Google, and if so is he still interested in being CC'd on Git stuff (maybe he'll chime

Re: What's cooking in git.git (Sep 2018, #03; Fri, 14)

Jeff King writes: >> > What's the donness of this one? >> > cf. <20180717201348.gd26...@sigill.intra.peff.net> >> >> This topic has stayed in 'pu' for a long time. I thought it was >> concluded that this was a good change? Jeff, Jonathan? > > I read over the thread again. I don't think I

Re: [PATCH v5 1/5] eoie: add End of Index Entry (EOIE) extension

On Mon, Sep 17, 2018 at 7:31 PM Junio C Hamano wrote: > > Duy Nguyen writes: > > > But it _is_ available now. If you need it, you write the extension > > out. > > Are you arguing for making it omitted when it is not needed (e.g. > small enough index file)? IOW, did you mean "If you do not need

You Won 2,000,000.00 pounds

Contact Account Officer For Claims: Mr Eric Elliot Francis Email: claim...@gmail.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Re: [PATCH v5 1/5] eoie: add End of Index Entry (EOIE) extension

Duy Nguyen writes: > But it _is_ available now. If you need it, you write the extension > out. Are you arguing for making it omitted when it is not needed (e.g. small enough index file)? IOW, did you mean "If you do not need it, you do not write it out" by the above? I do not think overhead

Re: [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content

On Mon, Sep 17, 2018 at 7:09 PM Junio C Hamano wrote: > > Nguyễn Thái Ngọc Duy writes: > > > This is about mixing "git add -p" and "git commit -a" (or "git commit > > ") where you may accidentally lose staged changes. After the > > discussion with Jonathan, I'm going with a bit different

Re: [PATCH v5 3/5] read-cache: load cache entries on worker threads

On 9/15/2018 6:31 AM, Duy Nguyen wrote: On Wed, Sep 12, 2018 at 6:18 PM Ben Peart wrote: This patch helps address the CPU cost of loading the index by creating multiple threads to divide the work of loading and converting the cache entries across all available CPU cores. It accomplishes

Re: Git for games working group

On Mon, Sep 17 2018, Joey Hess wrote: > Ævar Arnfjörð Bjarmason wrote: >> There's surely other aspects of that square peg of large file tracking >> not fitting the round hole of file locking, the point of my write-up was >> not that *that* solution is perfect, but there's prior art here that's

Re: [PATCH v5 2/5] read-cache: load cache extensions on a worker thread

Duy Nguyen writes: > On Sat, Sep 15, 2018 at 12:22 PM Duy Nguyen wrote: >> Wait there's no way to disable this parallel reading? Does not sound >> right. And if ordinary numbers mean the number of threads then 0 >> should mean no threading. Auto detection could have a new keyword, >> like

Re: [PATCH v2 0/1] Make 'git commit' not accidentally lose staged content

Nguyễn Thái Ngọc Duy writes: > This is about mixing "git add -p" and "git commit -a" (or "git commit > ") where you may accidentally lose staged changes. After the > discussion with Jonathan, I'm going with a bit different approach than > v1, this behavior now becomes default, and if the user

Re: Git for games working group

Ævar Arnfjörð Bjarmason wrote: > There's surely other aspects of that square peg of large file tracking > not fitting the round hole of file locking, the point of my write-up was > not that *that* solution is perfect, but there's prior art here that's > very easily adopted to distributed locking

Re: [PATCH] read-cache.c: fix a sparse warning

On 17/09/18 17:27, Ramsay Jones wrote: > > > On 17/09/18 15:15, Ben Peart wrote: >> >> >> On 9/16/2018 3:17 AM, Eric Sunshine wrote: >>> On Fri, Sep 14, 2018 at 7:29 PM Ramsay Jones >>> wrote: At one time, the POSIX standard required the type used to represent a thread handle

Re: [PATCH v4 02/23] read-cache.c: remove 'const' from index_has_changes()

On Mon, Sep 17, 2018 at 6:25 PM Junio C Hamano wrote: > > Nguyễn Thái Ngọc Duy writes: > > > This function calls do_diff_cache() which eventually needs to set this > > "istate" to unpack_options->src_index (*). This is an unfortunate fact > > that unpack_trees() _will_ destroy src_index so we

  1   2   >